CX Works

CX Works brings the most relevant leading practices to you.
It is a single portal of curated, field-tested and SAP-verified expertise for SAP Customer Experience solutions

Understanding the Message Broker in FSM to ECC Integration - (Part 1/2) Overview

6 min read

Table of Contents


One of the most important and least understood components in the standard integration between SAP Field Service Management (FSM) and Enterprise Resource Planning (ERP) Central Component( ECC), is the Message Broker.  In this first of two articles, I will provide an overview of the role of the Message Broker (MB), its technical requirements and useful information that help you accelerate to a successful integration project.

This article only applies to FSM to ECC integration.  The information for FSM to S/4HANA OP integration is quite different.


This standard integration product  is generally called the E4C connector, and it’s licensed by ProAxia to SAP as part of FSM standard integration.  This E4C package consists of 2 components:

  1. ECC transport package which is imported into ECC
  2. Set of executables which runs on Windows Server

To start from the top, the basic requirements for FSM to ECC integration are: 

  • SAP ECC 6.0 SP 19 or higher
  • SAP Netweaver 7.0 SP 14 or higher
  • Windows Server with .NET 4.7.2 or higher (to host the MB)



The architecture of a standard integration landscape can see in this diagram below - where the Message Broker (brown) is the middleware between the ECC and FSM Cloud.

The data flows from ECC on the left are created as IDocs which are converted into webservice calls to Message Broker (MB).  The MB receives this data record, and maps to the FSM fields, and calls the FSM oData API to transfer that information. These data flows from ECC can be master data or transactional data initiated from ECC. Each IDoc goes through three statuses. The sequence of the statuses on an IDoc starts at 03. Once the IDoc is sent to Message Broker, it's changed to 18.  Finally the MB will send a confirmation message back to ECC, which changes the status to 18.


The setup of the Message Broker is likely to be the last of the 3 components setup, as it depends on information from the setup of the first component (FSM Cloud Company) and the second component (ECC system).  The below will describe on a medium level as what information is needed.

Step A: Creation of FSM Cloud Company

A new Cloud Company is created using the Cloud Manager tool (provided by ProAxia). The most important point is that all master and transaction has to be created from the integration.  Master data cannot be entered manually in a FSM Cloud Company. The second important thing needed from this creation is the Access Token for the Message Broker config file.

Setup B: Setup of ECC environment

First the E4C transport has to be imported into ECC environment. Your technical consultant expert will guide you through all the detailed steps of this configuration. Our part 2 article will also provide a more detailed picture. The important components of this setup is to get the Technical Integration User ID and password as well as the webservice URLs created by the SOAManager step.

Finally when steps A and B are completed, the information can then be added to the configuration file, which is read by the Message Broker process on the Windows Server.

Message Broker Configuration Overview

As noted earlier, the message broker (MB) should be installed on a Windows Server with .NET 4.7.2 or higher.  The MB files are simply copied to a folder - see example below:

This Windows Server resides in the DMZ (demilitarized zone - a public network area accessible by ECC and external systems) and facilitates the data flows between ECC and FSM. The important thing to note is that FSM flows are initiated by the MB, which is polling at a frequent interval, so that it appears as almost real time. The FSM tenant is unable to initiate any data flows to MB.

The MB runs as a Windows Server and is a very lightweight middleware actor. It does not store any of the data packets so storage requirements are minimal. It is also quite resilient in its processing and generally the last component to be diagnosed as causing any integration issues.

The config file is highlighted in the files diagram, and this is the file that instructs the MB service on how to connect to ECC, and how to connect to FSM.  The SME will assist in the configuration by editing this file in notepad or notepad++.  An example of configuration the connection to FSM tenant is show below:

The setup of this file will be described in more detail in Part 2 of this article - for now, it's important to understand the holistic view of the Message Broker. 

Once the file is properly defined with the correct parameters for both ECC and FSM login, you can run a series of DOS prompt commands to create the Windows Service. Then you can easily administrate the start and stop of the MB service from the Control Panel. The MB is now a WIndows Service which accepts packets from ECC and sends to ECC. On the FSM side, it can convert those packets from ECC, map into the new fields for the OData API calls into FSM.  In addition, it will poll regularly the FSM system for any inbound data to ECC that it needs to process.


In conclusion, this article has described the requirements, architecture, dependencies of the Message Broker and how it all comes together and work.  In the resources section, a fact sheet link has been provided.  

If you are interested in the technical setup of the Message Broker, please continue to Part 2 of this article series (link to be provided when published).