This is a really rare scenario, but one to be aware of if you're using Unifi as a proxy though to push requests to multiple systems.
If you're integrating OOB ServiceNow Request process then you'll be using the ServiceNow Cart API in order to submit your inbound requests. This is how we set up all of our request integrations, its the sensible thing to do. Attempting to integrate request without it is asking for a lot of trouble, workflows, flows, domains, all end up being compromised when circumventing the cart API.
The downside to using the cart however is we are not in control of its behaviour. We've noticed a couple of things that can cause issues when dealing with multiple integrations on a request record:
the cart takes a long time to submit
additional updates to the request/requested item record are made during the cart submission process
Good question. Ordinarily they aren't if you are only integrating a request with one Unifi integration at a time. It's when you're using Unifi as a proxy to push requests to multiple systems that they can become a problem.
Unifi runs from trigger business rules on an integrated table. When the cart updates a requested item many times (and we're assuming you're integrating at the item level - most people do) then you will trigger Unifi multiple times. So picture this scenario, we receive and inbound request from Unifi integration A, we submit the request via the cart, which in turn then triggers Unifi, and more specifically Unifi integration B. Note that integration B has been triggered before integration A has completed, as it's the cart submission causing this save.
Now if we add the slow cart submission time (we see multiple updates on the requested item during this process which is likely why its slow), then we have an "interesting" scenario which can occur. Lets go back to the previous example, but lets make integration B a synchronous integration. We know that integration B has been triggered before integration A has finished its processing, and in fact this is before its bond has been committed, as the bond is committed at the end of the processing. Now with integration B being synchronous , and integration A slowed down by the cart submission process, it is actually possible for integration B to complete before integration A has! Yes, crazy, but true. Now this is where the problem lies. When we process the response for integration B, we update the request item with something like a work note or correlation ID. This then triggers the Unifi business rule which checks to see what integrations should fire. As we don't have the bond for integration A yet, Unifi decides that it should send a create message to integration A (as the create conditions will match - we received the create from A, makes sense we should send one for the same data too). Now we create a new (outbound) bond for integration A, and create a new request in their system for the request that they sent us! And finally the cart submission process finishes and submits the (inbound) bond. In the end we're left with a mess! Two bonds for the same integration on a requested item, and two requested items in system A for the same request. Yuck.
Don't despair, there's an easy fix to this issue and that is to prevent Unifi from sending messages whilst the cart submission is being performed. All you need to do is to wrap the cart.placeOrder() function with the x_snd_eb.Message.outboundEnabled() function, like so:
This prevents integration B from being triggered (well, any Unifi integrations for that matter) during the cart submission. Unifi updates the target (e.g. requested item) after processing the stage to target script, which will then trigger integration B after the bond for integration A has been completed, thus preventing duplicate bonds and tickets.