1. To-Increase Dynamics 365 for Finance & Operations
  2. Connectivity studio
  3. Operation
  4. Integration processes

Inbound web service process - Asynchronous

The inbound web service process is used to receive a request from and send a response to an external application, via an inbound web service.

The inbound web service can be an IIS application or Azure Logic Apps. This inbound web service receives the HTTP requests from the external application.
Depending on the execution mode, the inbound web service process runs directly or asynchronously. When triggered, the inbound web service action runs the defined messages.
This flow shows a general overview of the asynchronous inbound web service process.
How an asynchronous inbound web service is processed, depends on the execution mode. These asynchronous execution modes are supported:
  • Asynchronous: When the web service action is triggered, directly a default response text is sent back to the inbound web service. Also, the request message is run. Several request messages can run in parallel. Usually, no response message and error message are defined.
  • Batch: When the web service action is triggered, directly a default response text is sent back to the inbound web service. The data, as received by the web service request, is stored in the Inbound web service staging table. These staging table records are processed in batch. The batch job runs the request message as defined for the applicable web service action. Usually, no response message and error message are defined.


D365 FO (Handler class) D365 FO (Handler class) Web service Web service Inbound web service application  receives an HTTP request from the external application Inbound web service application  receives an HTTP request from the external application Inbound web service action is triggered Inbound web service action is triggered The inbound web service application triggers the applicable inbound web service action. Based on these parameters in the HTTP request, the inbound web service calls the executeWebserviceOperation method that determines which web service action is triggered: Project (ProjectId): Does a Connectivity studio project exist in D365 FO with this ID? Web service action (WebServiceId): Does an inbound web service action exist with this ID? HTTP action (HttpMethod): What is the goal of the HTTP request? Does this goal match with the HTTP action as defined for the web service action? User name (UserName): Is this user set up as web service user? And is this user allowed to run the web service action? URL (Url): If REST, does the URL contain arguments? And what are the values of these arguments? Content (content): For both the web service types (Basic or REST), if HTTP action is Post, Put, Delete, Patch, or Post or Put, the content contains the values to be processed. If the web service type is SOAP and the HTTP action is Get, the content contains the arguments of type parameter. What are the values of these arguments? Company ID (companyId): Is the web service action and web service user combination valid for this company? Inbound web service receives  default response text and  sends it to external application Inbound web service receives  default response text and  sends it to external application What is the asynchronous  execution mode? What is the asynchronous  execution mode? Record is created in the Inbound web service staging table Record is created in the Inbound web service staging table Inbound web service staging table records are processed in batch Inbound web service staging table records are processed in batch Web service request message is run Web service request message is run When triggered, the inbound web service action first runs the request message, if defined. This is managed by the handler class as defined for the web service action. The goal of the request message depends on the HTTP action of the web service action. In general, the request message provides D365 FO with data from the external application. If the HTTP action is: Post, use the request message to provide the data to be created in D365 FO.  Put, use the request message to provide the data to be updated in D365 FO. Get, no request message is used. The data to be get is defined by arguments. So, if the HTTP action is Get, set up the relevant arguments. Patch, use the request message to provide the data to be updated in D365 FO. Use this to only update a part of a record. For example, only update a contact person of a customer. Delete, use the request message to provide the data to be deleted from D365 FO. Post or put, use the request message to provide the data to be created or updated in D365 FO. For a request message the: Source connector must be of type Azure file storage or Web service Source document must be an external file-based document. Target connector must be of type D365 FO. Target document must be an internal document. End End Batch Asynchronous

Activities

Name Responsible Description

Inbound web service action is triggered

D365 FO (Handler class)
The inbound web service application triggers the applicable inbound web service action.
Based on these parameters in the HTTP request, the inbound web service calls the executeWebserviceOperation method that determines which web service action is triggered:
  • Project (ProjectId): Does a Connectivity studio project exist in D365 FO with this ID?
  • Web service action (WebServiceId): Does an inbound web service action exist with this ID?
  • HTTP action (HttpMethod): What is the goal of the HTTP request? Does this goal match with the HTTP action as defined for the web service action?
  • User name (UserName): Is this user set up as web service user? And is this user allowed to run the web service action?
  • URL (Url): If REST, does the URL contain arguments? And what are the values of these arguments?
  • Content (content):
    • For both the web service types (Basic or REST), if HTTP action is Post, Put, Delete, Patch, or Post or Put, the content contains the values to be processed.
    • If the web service type is SOAP and the HTTP action is Get, the content contains the arguments of type parameter. What are the values of these arguments?
  • Company ID (companyId): Is the web service action and web service user combination valid for this company?

Record is created in the Inbound web service staging table

D365 FO (Handler class)

Inbound web service staging table records are processed in batch

D365 FO (Handler class)

Web service request message is run

D365 FO (Handler class)

When triggered, the inbound web service action first runs the request message, if defined. This is managed by the handler class as defined for the web service action.
The goal of the request message depends on the HTTP action of the web service action. In general, the request message provides D365 FO with data from the external application.

If the HTTP action is:
  • Post, use the request message to provide the data to be created in D365 FO. 
  • Put, use the request message to provide the data to be updated in D365 FO.
  • Get, no request message is used. The data to be get is defined by arguments. So, if the HTTP action is Get, set up the relevant arguments.
  • Patch, use the request message to provide the data to be updated in D365 FO. Use this to only update a part of a record. For example, only update a contact person of a customer.
  • Delete, use the request message to provide the data to be deleted from D365 FO.
  • Post or put, use the request message to provide the data to be created or updated in D365 FO.
For a request message the:
  • Source connector must be of type Azure file storage or Web service
  • Source document must be an external file-based document.
  • Target connector must be of type D365 FO.
  • Target document must be an internal document.

See also

Provide feedback