Apex Code Development You need to sign in to do that
Don't have an account?
sdavidow9 Web Services, Callouts and Data Update timing
Wondering if anyone has run into a similar issue...I'll try to be brief with my explanation.
We are integrating 2 systems (SFDC and SAP) using custom ws and callouts - not outbound messaging.
When an "Order" (custom object) goes to a certain status, a process runs to send the Ordre to SAP. First thing we do is create a SAP Order Id (another custom field). We don't create the Id until the order is about to be sent to SAP because there is a limited # of Ids we can use (it's a range, so we don't want to loose ids for cancelled orders or orders that wont be integrated with SAP).
My code figures out what the next SAP Order Id should be and then sets it and does an "Update" on the List I'm holding the data in.
AFTER the update statement I make a callout to SAP where the order is created in SAP.
When SAP creates the Order, there is some backend processes on their side that run which in turn UPDATES the Order. These updates are sent back to SFDC. We don't get stuck in a loop because UPDATES in SFDC are NOT sent to SAP.
Since Orders can be created in SAP, when SAP sends an Order or Order Update to SFDC, we use the SAP Order Id to match to an existing order. If there isn't one, we assume it's new and create it.
This is where the problem comes in...it appears that my process that sets the SAP Order Id AND sends the Callout does not COMMIT the update to the SAP Ordre Id field until AFTER the Callout receives some sort of response from SAP.
The problem is that it seems SAP sends an UPDATE to SFDC BEFORE SFDC is finished processing the callout, so we are getting duplicate orders in SFDC - basically, SFDC decides that the SAP Order Id should be "XYZ", even though I say "UPDATE my Order" it waits until it hears a callout response. In the mean time SAP has received the create call, done it's magic and sent an update BACK to SFDC saying "there's an update to order XYZ" all before SFDC FINALLY updates the Order with the SAP Order Id.
I hope that all makes sense.
Basically, I need my SAP Order Id to be committed BEFORE a callout is made, but don't know how to do that since it's happening in the same class/call. The reason I believe it's a timing thing is because the SAP Order Id that's showing in the duplicate Order is the one sent to SAP - SAP would create it's own order with a different range.
Any thoughts?
Okay, okay, okay....several months ago I found out via posts (thanks to Ron Hess as it was one of his many posts) that you cannot do an update before a callout in an apex call. I don't know what constitutes "an apex call" as I tried moving them to separate classes, but anyway...
It was by design that the callout occures BEFORE the updating of the Order record with the new Id. Essentially, we wait for the ws respons from SAP before we update the record.
Appearently, SAP "fixed" itself recently and now it's running much faster, so it is creating the cooresponding Order in SAP, which triggers a web serivce call to SFDC. This outbound ws call (from SAP) is taking place before SFDC finishes processing the apex code that includes the callout (there are a few things happening for logging purposes), so an apex ws is being initiated that looks fore the Id that hasn't been committed.
Anyway, my solution now that I'm going to try and implement is to generate the Id I need based on a trigger off the Order Status. The callout will occure at a later date using either CronKit or (if I can figure it out) the new APEX scheduler.
Man...sometimes!
All Answers
"My code figures out what the next SAP Order Id should be and then sets it and does an "Update" on the List I'm holding the data in"
seems like the logic above is the problem. Instead of guessing the possible order Id before committing the record, try reading this order Id from the object. That way you are guaranteed to send an Id which does exist in the SFDC database.
If your integration requirement is not real-time then you may use Apex Scheduler to make the call outs at a certain interval.
Thanks...I probably wasn't clear. I'm creating the Order Id and then sending it to SAP...SAP is using a totally different range of numbers, so SFDC is the only one creating orders with this range. If SAP sends me an order with a number in my range, I know I created it.
I like your idea of reading the Order Id from the object...what I'd have to do is fire a second query rather than what I do now which is use the data I've already retrieved.
It doesn't run real time, but the creation of the Id and the subsequent sending of the order need to happen essentially at the same time...Client doesn't want the Order Id created (essentially using up the number range) unless the Order is ready to go to SAP.
We have CronKit running, but it's not working right for some reason. Apex Scheduler is another issue I'm trying to figure out :)...maybe a new post?
Okay, okay, okay....several months ago I found out via posts (thanks to Ron Hess as it was one of his many posts) that you cannot do an update before a callout in an apex call. I don't know what constitutes "an apex call" as I tried moving them to separate classes, but anyway...
It was by design that the callout occures BEFORE the updating of the Order record with the new Id. Essentially, we wait for the ws respons from SAP before we update the record.
Appearently, SAP "fixed" itself recently and now it's running much faster, so it is creating the cooresponding Order in SAP, which triggers a web serivce call to SFDC. This outbound ws call (from SAP) is taking place before SFDC finishes processing the apex code that includes the callout (there are a few things happening for logging purposes), so an apex ws is being initiated that looks fore the Id that hasn't been committed.
Anyway, my solution now that I'm going to try and implement is to generate the Id I need based on a trigger off the Order Status. The callout will occure at a later date using either CronKit or (if I can figure it out) the new APEX scheduler.
Man...sometimes!