Skip to main content
Technical Preview

Overview

SAP Field Service Management (now documented as SAP Field Service and Asset Management) plans and runs field service: service calls (tickets), activities (the jobs technicians do) and equipment at customer sites. This connector lets the broker open a service call and an activity when a machine raises an alarm, put run hours and other machine data on the equipment, and close the loop with business actions, so planners and technicians see what the machine sees. The template has two connectors:
  • SapFsmApi (SapFieldServiceManagementRestApi.lot), a client connector on your cluster host with 24 events: 13 writes, 10 reads and 1 token event. It has no DELETE or PUT events; cancel actions are business actions, not deletes.
  • SapFsmBusinessRuleReceiver (cmms_sap_fsm_webhook.lot), an optional server connector on port 9012 that receives calls from a Business Rule Webhook action and publishes them on MQTT.
SAP publishes the FSM API specs on the SAP Business Accelerator Hub, which needs an SAP login, so the events were picked by hand from the SAP Help Portal (Data API v4, Data Model, Query API, Service API, OAuth) and the SAP/fsm-sdk source.

Events

Every reply is published on the event topic plus /response. Data API replies wrap objects as {"data": [{"serviceCall": {...}}]} (lower-case DTO name).

Prerequisites

  • An SAP FSM company and its cluster: eu, de, us or au (China uses cn.fsm.sapcloud.cn). Change BASE_ADDRESS to https://<cluster>.fsm.cloud.sap. The older coresuite.com / coresystems.net hosts are being migrated to fsm.cloud.sap.
  • An OAuth client created in Account Admin (client id + secret) with a permission group that can read and write service calls, activities and equipment and run the Service Management actions.
  • The numeric account id and company id (Account Admin).
  • Outbound HTTPS from the broker to the cluster host.
  • For Business Rule webhooks only: a public HTTPS URL that forwards to the broker’s port 9012.

Authentication

The client secret and every access token act with the client’s permission group. Store base64(client_id:client_secret) in the Hub secret SAP_FSM_BASIC_AUTH (and the ids in SAP_FSM_ACCOUNT_ID / SAP_FSM_COMPANY_ID), read them with GET SECRET, and never put them or a token in a connector file.
GetToken posts grant_type=client_credentials to /api/oauth2/v2/token with HTTP Basic:
The reply carries access_token, token_type and expires_in. Every other event sends Authorization: Bearer {value.json.access_token}, X-Account-ID and X-Company-ID from the payload, and the fixed X-Client-ID: custom-coreflux-broker / X-Client-Version: 1.0 (SAP asks custom clients to use a custom- prefix). Call GetToken again before expires_in runs out. Answers seen from the real hosts without valid credentials: a fake client returns 401 {"error":"unauthorized","error_description":"Bad credentials"}, a Data API call without a token 401 INVALID_LOGIN, and any call with a fake token 401 {"error":"invalid_token"}.

Payload conventions

Each payload carries the context and the event’s own fields; the request body comes from body:
  • id is the 32-character FSM id; external_id is your id (alarm id, ERP equipment number). Both go into the path, so pass only values you trust.
  • query is a URL-encoded Data API condition, for example lastChanged%3E%3D1759737600000 (lastChanged>=1759737600000) for incremental polls.
  • Updates use optimistic locking: send the current lastChanged from a GET, or set force_update to "true".
  • PATCH .../externalId/<id> creates the object when it does not exist yet (send all mandatory fields).
  • Pages: default 20, page_size 1000 at most; replies carry currentPage, lastPage, totalObjectCount.
  • DTO versions are pinned: ServiceCall.27, Activity.43, Equipment.24.

Alarm to service call

Then attach the job (object points to the service call):
Or create both in one call with the Service Management API:

Machine data on equipment

udfValues reference a user-defined field you create for the equipment in FSM (here by its UDF meta externalId). UpdateEquipment patches standard fields such as remarks by FSM id.

Query API

dtos must list every DTO the CoreSQL statement uses, separated by ;.

Business Rule receiver

FSM has no webhook subscription API. Instead, a Business Rule (Admin > Company > Business Rules) with a Webhook action calls any URL with your headers and body when a service call, activity or other object is created or changed. Point it at:
Deploying the receiver opens port 9012. FSM calls out from the SAP cloud, so put a reverse proxy or tunnel with a public TLS certificate in front of it, allow SAP’s FSM egress addresses and check a shared secret header there: the connector does not authenticate callers.

Connector

Example actions

Notes

  • Writes run the company’s Business Rules and, if connected, sync to SAP S/4HANA or ECC.
  • Status, type, origin and priority codes and UDFs are company-specific: read an existing service call first and copy its codes.
  • SAP’s own fsm-sdk 4.0.1 still pins ServiceCall.26, Activity.39, Equipment.23. If your company rejects the newer versions, change the dtos= values in the endpoints.
  • The Service API pages also list X-Account-Name and X-Company-Name. The connector sends only the ids, like SAP’s SDK; add the name headers if a business action answers 400.
  • For Service Management calls the SAP Help pages use /service-management/api/v2/...; the SDK calls /service-management/v2/.... Both reach the API gateway; the connector uses the documented form.

Not covered

Deletes, full PUT replacement, the Data API batch endpoint, attachments, planning actions that need technician or team ids (plan, replan, reschedule, unassign), bulk actions, approvals and other DTOs (business partners, persons, service assignments, time efforts, materials, checklists). All use the same headers; add events in the same style.

Status

Technical preview, blocked. The template passes 357 of 357 smoke checks: static checks of both connectors against the SAP Help Portal pages and SAP’s fsm-sdk, every event against a local mock of the FSM APIs, negative controls, and calls to the real SAP FSM hosts with fake credentials (all rejected with 401). No call has run against a real SAP FSM company. To finish testing, use an SAP FSM test company: set SAP_FSM_CLUSTER, SAP_FSM_BASIC_AUTH, SAP_FSM_ACCOUNT_ID and SAP_FSM_COMPANY_ID, run python3 smoke_sap_fsm.py (and SAP_FSM_ALLOW_WRITE=1 to create one service call named “Coreflux smoke test (safe to delete)”), then run an MQTT round trip through the broker.
Last modified on October 21, 2026