SOAP integration with Service Catalog

robbika
Giga Contributor

We have an SOAP integration with the Service Catalog, but it is very complicated and I strongly suspect is not the correct way to do it.

Basically what happens is that a SOAP message comes in and a transform map sets the fields for the Request. The rest of the message is then processed in an After Transform Script to create the Requested Item and then after that there is complicated code to create copies of the variables from the catalog item definition and set them for the newly minted RITM. This is all very complicated and prone to errors.

On the ServiceNow wiki it mentioned using the Cart API. It has a caveat that the cart will be that of the SOAP user for SOAP integrations.

With all this in mind, I have some questions:

1) Is the Cart API the best way to go, instead of our code which has a role-your-own flavour to it?

2) If there is one user for all SOAP interactions, is there a danger that while one request is being processed, the cart is emptied for another concurrent transaction? Or doesn't it work that way? Or if it does work that way, how is this guarded against? (Locks?)

1 ACCEPTED SOLUTION

brian_quinn
ServiceNow Employee
ServiceNow Employee

Robert,



All of that should be possible using the Cart API and building a scripted web service.   The scripted web service can call the Cart API functions and then add the REQ number to the response of the SOAP message.



Thanks


Brian


View solution in original post

8 REPLIES 8

brian_quinn
ServiceNow Employee
ServiceNow Employee

Robert,



For your second question, there should not be a concern for concurrent transactions if you generate a unique id every time it runs.   For example I ran the following in Scripts - Background on a Fuji instance.   The script created 4 different carts, and waited to place the orders until all 4 carts were created.   It successfully creates 4 requests with 1 item in each request.   It should work the same for a SOAP integration.   IF you are not on Fuji you can run a similar test on your instance.



var cartId1 = GlideGuid.generate(null);


var cart1 = new Cart(cartId1);


cart1.addItem('e2132865c0a8016500108d9cee411699');



var cartId2 = GlideGuid.generate(null);


var cart2 = new Cart(cartId2);


cart2.addItem('e2132865c0a8016500108d9cee411699');



var cartId3 = GlideGuid.generate(null);


var cart3 = new Cart(cartId3);


cart3.addItem('e2132865c0a8016500108d9cee411699');



var cartId4 = GlideGuid.generate(null);


var cart4 = new Cart(cartId4);


cart4.addItem('e2132865c0a8016500108d9cee411699');




cart1.placeOrder();


cart2.placeOrder();


cart3.placeOrder();


cart4.placeOrder();



Thanks


Brian


Thanks for your answer.



We are on Eureka at the moment but I will try it out.


Please check my further analysis below.



(Not sure how thread notifications work.)


robbika
Giga Contributor

I've had a look at this for rewriting our terrible SOAP -> Request integration code.



The main issue I have is that when a message comes in, it is picked up in import set and transform map and the target is the Request table where a record is inserted and the number sent back to the SOAP caller.



Now the issue is that the Cart API has no way to attach a cart to an existing request. The placeOrder() call creates a request with a copyCart() method on it which is called to copy the items in the cart onto the request.



What I would need is some way to copy the cart onto the request that was just created by the transform map processing.



We have looked around an the GlideappRequestNew in the Cart API code is a Java something and doesn't seem to be specified anywhere.



So still at this point I don't see how to make this SOAP integration and pass back the correct Request number.