Optimizing Integration Configuration and Monitoring

Objective

After completing this lesson, you will be able to implement the Field Service Management (FSM) connector to support integration between SAP or third-party back-end systems and FSM.

Field Service Management Connector

Image showing the communication mechanisms when interfacing with the FSM Connector

Transactional data

The FSM connector is used to support integration between FSM on one side and SAP or third-party back-end systems on the other side. It covers the flow of transactional data, including the following:

  • Duplicate ServiceOrder (ServiceCall, Activity, ReservedMaterial)
  • Notify about updates during resolution phase
  • Final notifications about work completion together with related details:
    • timeEfforts / Expenses
    • Materials
    • Mileages

The inbound communication supports:

  • The creation and maintenance of transactional data, such as service calls and activities
  • Business actions, like assigning or releasing activities

The Inbound API is a proxy to the Field Service Management Service API. This means that details like request headers, query parameters, and request bodies will be the same for the Field Service Management Connector and Service API.

For the inbound communication, Service API should not be used directly. Instead, all calls should be made using the Field Service Management Connector as a proxy. Otherwise, unexpected behavior may occur, such as "circular updates".

master data

In case of Master Data communication where there is bi-directional communication, a request should also be done using fsm-connector (to avoid fsm-connector trigger back notifications to the caller system) to the following endpoint:

  • Method: POST / PATCH
  • URL: https://{hostname}/api/fsm-connector/v1/data/

The majority of objects that receive support in Data API v4 are likewise accommodated within the /fsm-connector/v1/data endpoint. However, there are exceptions, such as the following objects:

  • Time Effort
  • Material
  • Expense
  • Mileage

The fsm-connector behaves as a proxy in this case. All requests must be formatted as required by FSM Data API. For uni-directional data load to FSM, Data API should be used directly. For uni-directional mass load of master data to FSM, it is advised to use FSM Bulk API.

Image showing the configuration page for the FSM Connector and the integration properties for different integration types

FSM Connector configuration is performed in the Admin portal. The FSM Connector is enabled from the FSM Connector Enabled checkbox in the configuration screen.

Standard integrations are available for a number of SAP back-end systems. The integration types Other_WHOLE and Other_DELTA are available for 3rd-party systems.

The Outbound API can be set up with two different strategies:

  • Whole payload in conjunction with asynchronous communication
  • Delta payload in conjunction with synchronous communication.

All notifications are sent as HTTP POST requests with a JSON payload.

Depending on the selected integration type:

  • Different events, data objects, and payloads are supported
  • Different flags and settings can be maintained.

The Exclude Fields Classification  panel enables users to exclude the triggering of change events based on field classification.

Image showing the stored events and the error log of the FSM Connector

FSM Connector Stored Events (for SAP S/4HANA integration)

The Field Service Management Connector Stored Events screen in Admin displays all events that are currently stored and visible. These events are removed from this list by the Field Service Management Connector as soon as they are sent to CPI.

FSM Error Logs

Whenever there are errors when sending objects to the configured third-party in the Field Service Management Connector, they will be visible in the Field Service Management Connector Errors section.

It is possible to resend the notification to the third-party (CPI) by pressing the Retry button.

Log in to track your progress & complete quizzes