Skip to main content

How to problem solve Ecosystem Vendor Service Orders

AssignmentPro sends instructions to vendors to initiate services for assignments such as tax, immigration and relocation services. These instructions are called "Service Orders".  Service Orders are m

Updated over 2 weeks ago

AssignmentPro sends instructions to vendors to initiate services for assignments such as tax, immigration and relocation services. These instructions are called "Service Orders".

Service Orders are made up of several elements:

  • Initiations

  • Initiation Updates

  • Milestone Updates

  • Cancellations

Note, providers may have the capability of doing them all or just a combination of these used.

When service orders fail, you can troubleshoot them using the Integration Event History screen.

Integration Event History

The Integration Event History screen can be used to view a log of each integration event that has happened in the system. A detailed history of Ecosystem Service Orders will be recorded here and this screen can be used to resolve issues.

To access the page, navigate to the page under Configuration or System Level and selecting Integration Event History or using the global search. This includes the event logs which can be filtered using any combination of the provided fields including: Assignment ID, Service Order ID, Vendor, Status Type, Direction, Sub Type, Message and event history records can be filtered using a Date Range.

Screenshot of Integration Event History

This includes both outgoing and incoming activity as well as both successful and failed integration commands. This will display the date/time the request was sent, the result of the integration event, the type of integration event, which vendor record it was sent to, link to the note/communication and additional details.

Screenshot of Integration Event Logs section

For Outbound Events, the additional details available are as follows:

  • Request Sent to Vendor - This is the raw data (or ‘payload’) that was sent to the provider for the initiation.

  • Response - This is the response sent from the provider system back into AssignmentPro.

For Milestone Updates Events, the details available are as follows –

  • Details tab provides a high-level summary of the update event. This could include which records were updated, if there was a partial success along with basic error information.

  • Request Received from Vendor displays the raw data received from the Provider.

  • Response Sent to Vendor: shows the response AssignmentPro sent to the provider after the request was processed.

  • Errors tab shows the actual error encountered in the integration event

Note that the Integration Event History screen will only load the most recent 1,000 records and the page will store actual data that was sent up to 30 days. This will work in combination with any filter criteria supplied by the user, for example if a specific Vendor is selected, then the top 1,000 records for that Vendor will be displayed. When sorting results, the sort will only apply to those 1,000 entries.

Things to Note

  • Records on the GROW_INTEGRATION_EVENT_DETAILS table will now be retained for one month instead of 24 hours. This allows users with DB access or Equus technicians to retrieve raw data for inbound events from Vendors

  • Outbound requests to Vendors can be split out into multiple requests to Vendor systems:

    • Integration Events for Vendors that support this new handling will be set to a "Pending" status on the Event History screen, and will show "Awaiting Response" on Service Order screens. These new statuses indicate that the request has been successfully sent out of AssignmentPro and to the Vendor Hub, and is waiting for a response from the Vendor's system

    • Once a response has been received into the Vendor Hub from the Vendor and is sent to AssignmentPro, the status on the Service Order and Integration Event screens will be updated based on whether the request ultimately failed or succeeded in the Vendor's system

  • Additional retry logic can be set to have a specific number of retries to send a service order. This can be configured in a system Preference: Number of Retries when the Equus Hub is Unreachable (EQVINMRTEX)

Did this answer your question?