I'll read a little bit into your question and answer what I think you're looking for. I think you're asking about the scenario where ServiceNow acts as the front-end catalog for end-users and App Broker is coordinating license checks with FNMS and deployments with the deployment system(s). Note: There are other integration options where App Broker is the front-end and creates tickets in ServiceNow for things like failed deployments, but that's really just one-way communication.
In the scenario where ServiceNow is the front-end request portal for the user, there are communications happening in both directions. The catalog sync (I'll label this Interaction A) sends data from App Broker into ServiceNow (a mix of SOAP and REST calls). The self-service software request process sends data from ServiceNow to App Broker (REST calls - labeled as Interaction B) and App Broker updates Request/RITM status with the results of the deployment (SOAP calls - labeled as Interaction C). Having said that, I think what you're really asking is where does the network connection originate for each of those communications. It turns out that all network connections originate from inside the customer firewall. In interactions A and C, App Broker is making a direct call from the App Broker server through the firewall out to the ServiceNow instance in the cloud. In interaction B, ServiceNow is not making a connection from the cloud into the corporate intranet. Instead, ServiceNow puts instructions to be carried out into a queue. Then a MID server (installed on a server inside the corporate firewall) periodically reaches out to ServiceNow to see if there are any instructions waiting in the queue. If so, the MID server executes those instructions from inside the firewall directly to the App Broker server and then sends the response from that REST call back into the ServiceNow queue.
So the short answer is that data flows both directions, but connections are always initiated inside the corporate firewall. Does that help?
Anything expressed here is my own view and not necessarily that of my employer, Flexera. If my reply answers a question you have raised, please click "ACCEPT AS SOLUTION".
