An outbound web service action can only be triggered by D365 FO. When triggered, the outbound web service action automatically runs the defined messages.

You can run an outbound web service action on these levels:

  • Project: All related tasks are run. And for each task, all related web service actions are run.
  • Task: All related web service actions are run.
  • Web service action: Only used if an individual web service action must be run.
  • Data synchronization: The data synchronization setup of the web service action defines which records are processed.


Application Consultant Application Consultant Start Start How is the web  service action run? How is the web  service action run? Run project Run project You can use a project to exchange data. To be able to run a project, tasks must be set up for the project. If you run the project, all related tasks are run.Depending on the tasks that are set up for the project, you can use a project to run:An integration or data migration.Outbound web services.Batch classes.Master data management.Test cases.Usually, you run a project in batch. Based on the defined sub-projects and tasks dependencies, tasks are run in parallel. If you do not run the project in batch, all sub-projects and tasks are run sequentially. Procedure 1. Click Connectivity studio Integration Design. 2. Click Run project. 3. In the Project field, enter or select a value. Note: By default, the currently active project, as shown on the Connectivity studio Integration design workspace, is selected. 4. In the Company group field, enter or select a value. 5. Sometimes, you want to import only the delta, which are the changes since the last import. Example: During a migration project, often, some time elapses between the migration of the data and the go-live moment. Therefore, just before the go-live moment, you want to import the latest open transactions. However, you do not want to run the full migration again (see picture). In Connectivity studio, you can do a delta run. To do a delta run: - For the project tasks, add the applicable messages with the Run for delta field set to Run. - Set the current Delta run field to Yes. As a result, if the project is run, for each project task, only the messages are run that have the Run for delta field set to Run. When a message is run in a delta run, only the record inserts are done. So, no update or delete of records is done. Select Yes in the Delta run field. Note: For outbound web service actions, you can have set up data synchronization of type 'Date range'. To apply this data synchronization setup when you run web service actions from a project, select Yes in the Delta run field. 6. Select Yes in the Process outbound queue field. 7. Sub-task: Set up batch processing. 8. Expand the Run in the background section. 9. In the Batch processing field, select an option. If Yes, also fill in the other fields. 10. Click Recurrence and fill in the fields as desired. 11. Click OK. 12. Click OK. Notes You can also run a project from the project form. Run task Run task You can use a task to run the execution of:An integration or data migration. In this case, use a task with the desired messages defined.Outbound web services. In this case, use a task with the desired outbound web service actions defined.Batch classes. In this case, use a task with the desired batch classes defined.Master data management. In this case, use a task with the desired master data entities defined.Test cases. In this case, use a task with the desired messages with test cases defined.If you run a task, all defined messages, outbound web service actions, batch classes, and master data entities are run.Usually, you run a task by running the related project. In this case, all tasks of the project are run, taking into account the defined task dependencies. However, you can run a single task, for example, for testing purposes. Procedure 1. Click Connectivity studio Integration Design. 2. Click Tasks. 3. In the list, find and select the desired task. 4. On the Action Pane, click Operation. 5. Click Run task. 6. Select Yes in the Process outbound queue field. 7. Sub-task: Set up batch processing. 8. Expand the Run in the background section. 9. In the Batch processing field, select an option. If Yes, also fill in the other fields. 10. Click Recurrence and fill in the fields as desired. 11. Click OK. 12. Click OK. Run web service action  from a button? Run web service action  from a button? Run web service action Run web service action If you want to run an outbound web service action immediately, you can run it from the Web service action page. Procedure 1. Click Connectivity studio Integration Design. 2. Click the Web service tab. 3. In the list, find and select the desired outbound web service action. 4. Click Edit. 5. On the Action Pane, click Operation. 6. Click Run. 7. Select Yes in the Process outbound queue field. 8. For the outbound web service action, you can have set up data synchronization of type 'Date range'. To apply this data synchronization, do a delta run. Select Yes in the Delta run field. Note: You can also apply the 'Date range' data synchronization setup if you run the web service action by running a project. In this case, for the project run, select Yes in the Delta run field. 9. Sub-task: Run recurring. 10. Expand the Run in the background section. 11. Select Yes in the Batch processing field and fill in the other fields as desired. 12. Click Recurrence and fill in the fields as desired. 13. Click OK. 14. Click OK. 15. Close the page. Run web service action from a button

Run web service action from a button

You can use button on a form to run an outbound web service action. You can add a button to a form in these ways:

  • Dynamic button
    Use a dynamic button to manually start an outbound web service action from a form.
  • Action menu item
    Use a custom action menu item to manually start an outbound web service action from a form. For the action menu item, custom coding is required.

Process data synchronization log Process data synchronization log For messages and web service actions, you can use table events to track data changes. You can define, for each table, which table events are logged. The table events are logged in the Data synchronization log.To fully process the logged events, process the: Data synchronization log: The logged events are processed and for each applicable message or web service action, a record is added to the Outbound queue. Outbound queue: For each record, the related message or web service action is run to export the applicable data. This topic explains how to process the data synchronization log.   @videoref:CS5 Note: Events are logged only for tables and event types that are defined in the data synchronization setup of any message or web service action. If on the data synchronization setup, the Update check box and the Check used fields check box are selected, event logging is restricted to changes to the fields as defined for the record in the applicable source document. Only the event is logged and used for further processing. So, in case of an update, an event is logged of type Update. However, the changed data is not marked as changed and not used for further processing. For example, if you change a customer address, an event is logged that the customer is updated. However, the address change as such is not logged. When, for the logged event, a record is processed in the outbound queue, the then current data of the customer is used. If a logged event is processed, it is deleted from the data synchronization log. Example: This table gives examples of the results for several data synchronization log processing scenarios: Number of pages Page size Limit records Number of records to be processed Result 5 10,000 No 40,000 4 pages of 10.000 records are processed 5 10,000 Yes 40,000 4 pages of 10.000 records are processed 5 10,000 No 80,000 5 pages of 16.000 records are processed 5 10,000 Yes 80,000 5 pages of 10.000 records are processed   Procedure 1. Click Connectivity studio Integration operations. 2. Click Process data synchronization log. 3. To improve the performance when processing a lot of logged events, you can use paging. For paging, the logged events are split over several pages that are run in parallel batch tasks. It can be that you can run only a limited number of batch jobs in parallel or that you want to use a limited number of batch jobs. If so, define the maximum allowed number of pages. In the Number of pages field, enter a number. Note: If the number of records to be processed is less than the the defined 'Number of pages' x 'Page size', less than the defined number of pages are processed. 4. You can split the records to be processed over several pages (batch tasks). Define the number of events to be processed by one batch task (page). In the Page size field, enter a number. Note: If the number of records to be processed exceeds the defined 'Number of pages' x 'Page size', and 'Limit records' is set to: No, the number of records per page is increased to get all records processed. Yes, the maximum number of records per page is fixed. So, not all records are processed. 5. Select Yes in the Limit records field. 6. Usually, all records in the data synchronization log are processed. However, you can also process a number of oldest records only. For example, if you fill in '100', only the 100 oldest records are processed. This can be helpful to investigate if issues occur when processing older records. In the Oldest set of field, enter a number. Note: If you enter a number in the 'Oldest set of' field, these fields are not considered: Number of pages Page size Limit records 7. Sub-task: Set up batch processing. 8. Expand the Run in the background section. 9. Select Yes in the Batch processing field and fill in the other fields as desired. 10. Click Recurrence and fill in the fields as desired. 11. Click OK. 12. Click OK. Notes You can also process specific data synchronization log records. To do so: Go to Connectivity studio > Inquiries > Data synchronization log. Select the records to be processed. Click Process selection. Process outbound queue Process outbound queue For messages and web service actions, you can use table events to track data changes. You can define, for each table, which table events are logged. The table events are logged in the Data synchronization log. To fully process the logged events, process the: Data synchronization log: The logged events are processed and for each applicable message or web service action, a record is added to the Outbound queue. Outbound queue: For each record, the related message or web service action is run to export the applicable data. This topic explains how to process the outbound queue.   @videoref:CS5   Outbound queue The outbound queue only has unique entries for each combination of: Record on which the event was logged Message or web service action Event type Status Note that the record and event type are known, but the (changed) data of the records is not known. When an outbound queue entry is processed, the current data of the record is used. For example, if a customer address is changed, an event is logged that the customer is updated. However, the address change as such is not logged. When, for the logged event, a record is processed in the outbound queue, the current data of the customer is used. Bundling In the outbound queue, several entries can exist for a unique message or webservice action. How these entries are processed, depends on whether bundling is active. You can activate bundling on the data synchronization setup of an outbound: Message: On processing the outbound queue, by default, all entries for a unique message are bundled in one message run, which results in one file.  Web service action: On processing the outbound queue, by default, all entries for a unique web service action are bundled in one web service action run, which results in one file. Note: You cannot apply bundling to an outbound web service action that uses a stream. EDI document flow: On processing the outbound queue, the entries are bundled in one message run or web service action run, which results in one file. In this case, the outbound queue entries are bundled by the applicable EDI party. If the bundling field is set to: Yes, all outbound queue entries for the message are bundled and processed in one message run, which results in one file. No, each outbound queue entry is processed in a separate message run. Processing the outbound queue You can process the outbound queue in several ways. To process the outbound queue for: All records, do not define a message or web service action. A specific message, define the message. A specific web service action, define the web service action. You can also run the outbound queue for a specific project. To do so, when you run a project, set the Process outbound queue field to Yes. As a result, the outbound queue is processed for the messages or web service actions that are linked to the project tasks. If an outbound queue record is processed, it gets the status: Processed, if it is processed successfully. Error, if errors occurred during processing. Procedure 1. Click Connectivity studio Integration Design. 2. Click Process outbound message queue. 3. You can process the outbound queue for a specific message. In the Message field, enter or select a value. Note: - If you want to process the outbound queue for a specific message, do not define a web service action. If you define a web service action as well, the outbound queue is only processed for the web service action. - If you do not define a message or web service action, the full outbound queue is processed. 4. You can process the outbound queue for a specific web service action. In the Web service action field, enter or select a value. Note: If you do not define a message or web service action, the full outbound queue is processed. 5. In the Company field, enter or select a value. 6. Sub-task: Set up batch processing. 7. Expand the Run in the background section. 8. Select Yes in the Batch processing field and fill in the other fields as desired. 9. Click Recurrence and fill in the fields as desired. 10. Click OK. 11. Click OK. Notes If an outbound queue record for a web service action has run with errors, the maximum number of retries is checked. If the maximum number of retries is: Not reached, the outbound queue record gets the status New. The next time the outbound queue is processed, the record is processed again. Reached, the outbound queue gets the status Error. The maximum number of retries is shown in the Max. retries field of the outbound queue record. The value of this field is defined in the Max. automatic retries of web services field in the Connectivity studio parameters. The number of retries that are already done, is shown in the Times tried field of the outbound queue record. For each retry, the value of this field is increased with 1. End End Project Task Web service action Table events No Yes

Activities

Name Responsible Description

Run project

Application Consultant

You can use a project to exchange data. To be able to run a project, tasks must be set up for the project. If you run the project, all related tasks are run.
Depending on the tasks that are set up for the project, you can use a project to run:
  • An integration or data migration.
  • Outbound web services.
  • Batch classes.
  • Master data management.
  • Test cases.
Usually, you run a project in batch. Based on the defined sub-projects and tasks dependencies, tasks are run in parallel. If you do not run the project in batch, all sub-projects and tasks are run sequentially.

Run task

Application Consultant

You can use a task to run the execution of:
  • An integration or data migration. In this case, use a task with the desired messages defined.
  • Outbound web services. In this case, use a task with the desired outbound web service actions defined.
  • Batch classes. In this case, use a task with the desired batch classes defined.
  • Master data management. In this case, use a task with the desired master data entities defined.
  • Test cases. In this case, use a task with the desired messages with test cases defined.
If you run a task, all defined messages, outbound web service actions, batch classes, and master data entities are run.
Usually, you run a task by running the related project. In this case, all tasks of the project are run, taking into account the defined task dependencies. However, you can run a single task, for example, for testing purposes.

Run web service action

Application Consultant

If you want to run an outbound web service action immediately, you can run it from the Web service action page.

Run web service action from a button

Application Consultant

You can use button on a form to run an outbound web service action. You can add a button to a form in these ways:

  • Dynamic button
    Use a dynamic button to manually start an outbound web service action from a form.
  • Action menu item
    Use a custom action menu item to manually start an outbound web service action from a form. For the action menu item, custom coding is required.

Process data synchronization log

Application Consultant

For messages and web service actions, you can use table events to track data changes. You can define, for each table, which table events are logged. The table events are logged in the Data synchronization log.To fully process the logged events, process the:

  1. Data synchronization log: The logged events are processed and for each applicable message or web service action, a record is added to the Outbound queue.
  2. Outbound queue: For each record, the related message or web service action is run to export the applicable data.

This topic explains how to process the data synchronization log.

 


Note:

  • Events are logged only for tables and event types that are defined in the data synchronization setup of any message or web service action.
  • If on the data synchronization setup, the Update check box and the Check used fields check box are selected, event logging is restricted to changes to the fields as defined for the record in the applicable source document.
  • Only the event is logged and used for further processing. So, in case of an update, an event is logged of type Update. However, the changed data is not marked as changed and not used for further processing. For example, if you change a customer address, an event is logged that the customer is updated. However, the address change as such is not logged. When, for the logged event, a record is processed in the outbound queue, the then current data of the customer is used.
  • If a logged event is processed, it is deleted from the data synchronization log.

Example:

This table gives examples of the results for several data synchronization log processing scenarios:

Number of pages Page size Limit records Number of records to be processed Result
5 10,000 No 40,000 4 pages of 10.000 records are processed
5 10,000 Yes 40,000 4 pages of 10.000 records are processed
5 10,000 No 80,000 5 pages of 16.000 records are processed
5 10,000 Yes 80,000 5 pages of 10.000 records are processed

 

Process outbound queue

Application Consultant

For messages and web service actions, you can use table events to track data changes. You can define, for each table, which table events are logged. The table events are logged in the Data synchronization log.
To fully process the logged events, process the:
  1. Data synchronization log: The logged events are processed and for each applicable message or web service action, a record is added to the Outbound queue.
  2. Outbound queue: For each record, the related message or web service action is run to export the applicable data.

This topic explains how to process the outbound queue.

 

 

Outbound queue
The outbound queue only has unique entries for each combination of:
  • Record on which the event was logged
  • Message or web service action
  • Event type
  • Status
Note that the record and event type are known, but the (changed) data of the records is not known. When an outbound queue entry is processed, the current data of the record is used. For example, if a customer address is changed, an event is logged that the customer is updated. However, the address change as such is not logged. When, for the logged event, a record is processed in the outbound queue, the current data of the customer is used.
Bundling

In the outbound queue, several entries can exist for a unique message or webservice action. How these entries are processed, depends on whether bundling is active. You can activate bundling on the data synchronization setup of an outbound:

  • Message: On processing the outbound queue, by default, all entries for a unique message are bundled in one message run, which results in one file. 
  • Web service action: On processing the outbound queue, by default, all entries for a unique web service action are bundled in one web service action run, which results in one file. Note: You cannot apply bundling to an outbound web service action that uses a stream.
  • EDI document flow: On processing the outbound queue, the entries are bundled in one message run or web service action run, which results in one file. In this case, the outbound queue entries are bundled by the applicable EDI party.

If the bundling field is set to:

  • Yes, all outbound queue entries for the message are bundled and processed in one message run, which results in one file.
  • No, each outbound queue entry is processed in a separate message run.
Processing the outbound queue
You can process the outbound queue in several ways. To process the outbound queue for:
  • All records, do not define a message or web service action.
  • A specific message, define the message.
  • A specific web service action, define the web service action.
You can also run the outbound queue for a specific project. To do so, when you run a project, set the Process outbound queue field to Yes. As a result, the outbound queue is processed for the messages or web service actions that are linked to the project tasks.
If an outbound queue record is processed, it gets the status:
  • Processed, if it is processed successfully.
  • Error, if errors occurred during processing.

Run web service action from a button

Provide feedback