1. To-Increase Dynamics 365 for Finance & Operations
  2. EDI studio
  3. Activities

Set up web service action - Inbound
Application task

You can use the inbound web service process to receive a request from and send a response to an external application, via an inbound web service.

For each inbound web service action, you can define these messages:
  • Request message: The request message provides D365 FO with data from the external application.
  • Response message: The response message sends the response from D365 FO to the inbound web service.
  • Error message: The error message sends the error information from D365 FO to the inbound web service.
An inbound web service action can only be triggered by an inbound web service. When triggered, the inbound web service action automatically runs the defined messages.


Standard procedure

1. Click Connectivity studio Integration Design.
2. Click the Web service tab.
3. Click New.
4. In the Web service action field, type the unique name of the web service action.
5. In the Project field, enter or select a value.
6. Define the goal of the inbound web service:
- Post: Create records in D365 FO.
- Put: Update records in D365 FO.
- Get: Get data from D365 FO.
- Patch: Update only a part of records in D365 FO.
- Delete: Delete records from D365 FO.
- Post or put: Create or update records in D365 FO. Based on the received data, D365 FO determines whether data is updated or created.
  In the HTTP action field, select an option.
7. Sub-task: Set web service action properties.
  7.1 Expand the Properties section.
  7.2 Define the direction of the web service action.
  In the Acts as field, select 'Inbound'.
  7.3 Define the access type of the web service:
- Basic: You can use this option if the web service access type is SOAP (Simple Object Access Protocol).
- REST: Use this option is the web service access type is REST (Representational State Transfer).
  In the Web service type field, select an option.
  7.4 Define the execution mode of the inbound web service. Depending on the execution mode, the inbound web service process runs directly or asynchronously.
These asynchronous execution modes are supported:
- No: When the web service action is triggered, the request message is run. Depending on the result and setup, also a response message or error message is run.
- Asynchronous: When the web service action is triggered, directly a default response text is sent back to the inbound web service and the request message is run. Several request messages can run in parallel. Usually, no response and error message are used.
- 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, running the applicable request message. Usually, no response and error message are used.
  In the Run asynchronously field, select an option.
  7.5 Define the request message 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.
  In the Request message field, enter or select a value.
 

Note: If the HTTP action is Get, no request message is used.
  7.6 Define the response message for the web service action.
The goal of the response message depends on the HTTP action of the web service action. In general, the response message sends the response from D365 FO to the inbound web service.
  In the Response message field, enter or select a value.
  7.7 You can define an error message for the web service action.
The error message processes the error from D365 FO to the inbound web service.
  In the Error message field, enter or select a value.
8. Sub-task: Set up arguments.
  8.1 If the HTTP action of an inbound web service action is Get, you can use arguments to specify the requested data. The argument values are used as input for the response message. In this way, only the requested data is sent to the external application.
  Expand the Arguments section.
  8.2 Click New.
  8.3 Each argument is used to get the value for a document field of the source document of the response message.
  In the Document field field, enter or select a value.
  8.4 Use the range type to indicate how the document field value of the source document of the response message is defined.
You can use these types:
- Value: Use a fixed value for the document field.
- Custom: Use a static method to define the value of the document field.
- Parameter: Use a value of a parameter in the HTTP request as the value for the document field.
  In the Range type field, select an option.
 

Note: If the range type is Parameter and the web service type is:
- REST, the parameter is added to the URL as shown in the Properties section. On receipt of the HTTP request, the parameter value is retrieved from the HTTP request URL and used as value for the document field.
- Basic (SOAP), make sure the parameter argument names are communicated to the external application. These parameters must be added to the content of the HTTP request. On receipt of the HTTP request, the parameter value is retrieved from the HTTP request content and used as value for the document field.
  8.5 If the range type is:
- Value, enter a fixed value or a range of values, using the right syntax. Examples: '10', '10,20', or '10..40'.
- Custom, enter a static method to define the range. Examples: 'curExt()' (gets the current company), 'strFmt("%1..%2", prevMth(today()), today())' (gets the orders from the last month), and 'DateTimeUtil::utcNow()' (filters on the current date/time).)
- Parameter, enter the name of the parameter.
  In the Range field, type a value.
  8.6 The style is only applicable if the web service type is REST and the range type is Parameter.
For an inbound web service action, only these styles are applicable:
- QUERY
- TEMPLATE
  In the Style field, select an option.
 

Note: If you use parameter arguments and the web service type is REST, the sequence of the arguments is important. You can use the Move up and Move down buttons to change the argument sequence.
9. Sub-task: Set custom handler.
  9.1 Expand the Custom section.
  9.2 For an inbound web service action, the standard handler classes are:
- BisWsServerHandler: Runs the inbound web service action. For the request message, the source connector must be of type Azure file storage. For the Response message and error message, the target connector must be of type Azure file storage.
- BisWsServerHandlerV3: Runs the inbound web service, using streaming. For the request message, the source connector must be of type Web service. For the Response message and error message, the target connector must be of type Web service.
You can use a customized handler class. To do so, extend a standard handler class.
  In the Handler field, enter or select a value.
10. Sub-task: Set history settings.
  10.1 Expand the History section.
  10.2 You can create a report in Microsoft Excel format that contains the errors that occurred during a web service action run. You can, for example, use this to inform the sender of data on the errors. The report is created when the web service action run is finished. The report is stored in the folder as defined in the Business integration parameters, in the History report path field.
  Select Yes in the Create history report field.
11. Close the page.

Notes

In the Properties section, the URL to trigger the inbound web service action is shown. When you have finished the setup of the inbound web service action, you can communicate the URL to the external application. So, they can use it to call the inbound web service to get the requested data.

This URL consists of these parts, in this sequence:
- IIS application path: To be filled in manually before you communicate the URL to the external application. If you use Azure Logic Apps as inbound web service, this part of the URL is not applicable.
- biswebservice: This is a fixed part of the URL that is added automatically. So, each URL always contains this part.
- Web service type as defined for the web service action.
- HTTP action: Only added if the web service type is Basic (SOAP).
- Project of the web service action.
- Web service action name.
- Parameter of type TEMPLATE, if defined as argument. In the URL, template parameters are always positioned between the web service action name and QUERY parameters. A template parameter is shown between braces ({}). This is only added if the web service type is REST.
- Parameter of type QUERY, if defined as argument. In the URL, query parameters are always positioned at the end and preceded with a question mark (?). This is only added if the web service type is REST.
On the web service action page, the URL can, for example, be:
  • [Your URL]/biswebservice/rest/Project1/IWSA-Customer/{TemplateParameter1}?QueryParameter1=Your Value
  • [Your URL]/biswebservice/SOAP/Post/Project1/IWSA-Customer

See also

Provide feedback