Sepasoft Business Connector and Web Services: linking ERP and SAP to MES on Ignition, B2MML mapping and errors

Production orders and material lists usually live in ERP, while the record of what each line actually made lives at the plant level. On Ignition, Sepasoft, Inc. links the two with three modules: Business Connector, which runs integrations drawn as charts; Web Services, which calls and serves REST and SOAP interfaces; and the Interface for SAP ERP, which adds SAP connectivity to Business Connector. This article explains, from Sepasoft's MES Module Suite user manual and product pages, how orders and materials reach the MES modules, how results go back, how errors are handled, and what we settle with the ERP team before building anything. Which Sepasoft module fits which plant need: Sepasoft MES modules.

1. The three modules

Sepasoft groups its ERP connectivity into these three modules. Ignition itself is the platform from Inductive Automation; the modules are installed on the Ignition gateway.

Business Connector works alongside both MES 2.x and MES 3.x modules, but with MES 2.x the blocks that handle MES objects, such as Verify MES Object and Save MES Object, are not available.

2. What goes down, what comes up

Sepasoft's ERP connectivity tutorial describes two directions. Southbound, a production order created in ERP is pulled into the MES layer, which tells the SCADA and HMI layer what to make and when. Northbound, once the order is complete, the MES pushes back to ERP what happened during production. This is the ISA-95 boundary between level 4 and level 3; the categories of information that cross it are covered in the ISA-95 article.

Business Connector uses B2MML, which Sepasoft describes as the XML implementation of ISA-95 (IEC/ISO 62264). In its example of a typical exchange, a production performance object holds production responses, and their segment responses carry the measured production and material consumption.

Below the MES modules, line data passes through Ignition tags. An MES counter takes its count from an Ignition tag, which can be a PLC counter, a memory tag or a SQL value, and Settings and Changeover can use OPC tags from the PLC for setpoints. In Ignition 8.1, an OPC tag is driven by an OPC server and an OPC item path, which points to a device connection.

3. How a chart is built and started

Sepasoft describes a chart as a configurable flowchart for data moving between a business system and the Ignition server, meaning the MES modules, Ignition tags or both. It is created in the Ignition Designer, in the Global area of the Project Browser under Business Connector. Blocks are placed on a design grid and linked with connector arrows into a linear, decision-based or iterative sequence. The blocks Sepasoft lists are Start, Decision, Iteration, Exception, Script, Enclosing Chart, End, Aggregation, Verify MES Object, Save MES Object, SAP BAPI Action, SAP RFM Action, SOAP Action and RESTful Action.

Sepasoft stresses one point: the arrows pass only execution control from one block to the next. Data moves separately, through each block's mapping between the business system schema, B2MML structures and the chart parameters defined in the Start Block. A Script Block can read and write those parameters and use the system.mes script functions, which mainly work with MES objects.

Sepasoft's product page lists four ways to start a chart: a schedule, a tag change, a web service call or a script function. From a script, system.mes.bc.executeChart, called with a chart path and optionally a dictionary of parameters, starts a chart and returns at once without waiting for it to finish; system.mes.bc.executeChartSynchronous is the version that waits, and a form that also lists chart parameters to return waits and hands them back as a dictionary. Passing a parameter that the Start Block does not define throws an exception. In Ignition 8.1, gateway event scripts include Timer, Tag Change and, from 8.1.6, Scheduled scripts, and they run on the gateway whether or not any client is open.

4. From ERP data to MES objects

Sepasoft's product page names OEE, Settings and Changeover and Track and Trace as modules that receive the mapped data, such as schedules and material definitions; how Track and Trace uses lots and operations is covered in Sepasoft Track and Trace. The mapping pane has two tabs. Input maps business system data, or a chart parameter, into a B2MML structure or chart parameter; Output maps B2MML structures or chart parameters back into the business system. A mapping connection can carry a Python script to clean, convert, filter or check the data, and several source properties can feed one destination, for example material type and description joined into one description. Properties of different data types can be connected, but the conversion has to be written as a script. Destination properties marked Required must be connected, or confirmed as not actually needed, or an error occurs when the chart runs; in some cases connecting one of several Required properties is enough.

Many B2MML structures can be mapped, among them ProductionSchedule, ProductionPerformance, OperationsPerformance, Equipment, Personnel and PhysicalAsset. The Save MES Object block, however, creates MES objects from only five of them:

A Verify MES Object block can test a row before saving: it creates nothing, and sends rows that would not make a valid MES object to its No output, typically a script that handles the error or the next loop of an Iteration block.

5. Errors and retries

The Exception block checks whether the chart has thrown an error and sends control to its Yes or No output. Sepasoft's examples show both handling styles: skip the save and end the chart, or repair the bad or null data in a Script block and then save. Several Exception blocks can sit at different points of one chart; in Sepasoft's example, each error path sets a flag parameter that is returned to the calling script, which then knows which step failed and whether any objects were created. While testing, Sepasoft suggests raising the gateway logger for chart execution from INFO to DEBUG.

On the web services side, a RESTful consumer has a timeout, a maximum number of retries after a connection failure (3 by default), and an option to throw an exception when the call returns an HTTP error code such as 404. For SAP calls, the RFC type decides what happens when SAP is not available: with sRFC the receiving system must be available at the time of the call; tRFC runs the function exactly once and keeps the call in a local queue while SAP is unreachable; qRFC works like tRFC and also keeps the calls in order.

6. Ignition as a web service provider

With Web Services, ERP or another system can also call the Ignition gateway, rather than only being called by it. RESTful endpoints are mounted under /main/system/ws/rest and answer GET, POST, PUT and DELETE with a Python script per method, in JSON or XML. SOAP endpoints are mounted under /main/system/ws/soap, a WSDL file can be imported or exported, and the WSDL is served at the endpoint address followed by ?wsdl. Both endpoint types can redirect plain HTTP to the gateway's SSL port and can require HTTP Basic authentication against an Ignition user source, optionally limited to certain roles; missing credentials return 401 and wrong ones 403. As a consumer, a RESTful configuration supports HTTP Basic, Digest, NTLM and OAuth, with a choice of OAuth strategy from version 3.81.10 SP7.

7. SAP through the Interface for SAP ERP

The Interface for SAP ERP can call any remote-enabled function module (RFM) of the SAP installation and lists the available BAPIs from SAP's Business Object Repository, with sRFC, tRFC and qRFC supported. Sepasoft's manual says the SAP team has to be involved early, and lists what it must provide: the SAP JCo library matching the operating system and architecture of the Ignition gateway server, an SAP user with authorisation to call the BAPIs and RFMs the project needs, and the host, system number and client of the development SAP server. From version 3.81.10 RC1, Business Connector can also act as a server, so SAP can call a function that runs a chart: the chart runs synchronously, only sRFC calls are supported in this direction, and errors are returned to SAP in the RETURN structure.

What TDL checks first

These are our working habits, not Sepasoft requirements:

• Master data ownership. We list which system owns material numbers, work order numbers and lot numbers, and check that the IDs ERP sends cover the minimum mapping Save MES Object needs.
• Every message and its direction. We write each message with its direction, its trigger (an order released, an order completed, a scheduled poll) and whether ERP pulls from Ignition or Ignition calls ERP.
• The error queue. We agree where a failed message waits, who is told, and who sends it again, before the first chart is built. The Exception block only routes the error: the plant still needs a person who owns it.
• A test system on both sides. We check that a development ERP or SAP client is available, so charts are tested without touching production orders.

How TDL approaches it

TDL Industrial Automation is a Sepasoft MES Certified Integrator and an Ignition Certified Integrator. TDL scopes and configures Sepasoft modules on Ignition and connects them to the line PLCs, so that machine states, counts, alarms and recipe values come from the existing controllers. More on this service: MES on Ignition with Sepasoft.