Supply Chain Event Management (SCEM) Described

• It controls the correct sequence of business steps
• It monitors the timings of reporting of expected events / milestones. i.e Were they reported on time? Were they reported at all? This is known as overdue monitoring.
• It monitors data of reported events. Each event reports data to SCEM and SCEM can check that this data was expected and falls within pre-determined limits
• It measures the quality of the process by comparing it to predetermined quality goals

Within a given process you have events that you expect to happen and then you have events that actually happen. In total there are 4 types of events:

• On time Event: The first event is an event that you expect to happen at a certain time in relation to the process and it happens in that time frame.
• Early / Late Event: The event is reported outside the limit that was set as the expected event. It could cause rescheduling of subsequent tasks, email notifications, alerts, …
• Unexpected Event: This event is reported yet was not expected in the standard overall business process as defined.
• Unreported event: An event that you expect to have been reported by a certain time, that is not reported at all, is referred to as an unreported event.

The Application System (AS) is any system that holds application objects managed by Event Management (EM). It need not be an SAP system. Event Management (EM): mySAP SCM Application for handling SCEM. When you process application objects in your AS you check to see if an event handler (EH) needs to be created in SCEM. This is referred to as AOT Relevance checking. Once relevance is determined then data is collected to pass to SCEM. Eg. Control parameters, Info, Query, expected events, business object reference, tracking ID.

What are the components of SCEM?

Business Process Types

The type of business process / object for which events are managed. The following is a list of the standard BPTs provided in ECC

Application Object Types (AOT)

A distinct business object type / BPT, or parts thereof, that is relevant for EM makes up an AOT. 1 BPT can have several AOTs. You assign the SCEM-relevant application object types to the business process types. SAP Event Management (SAP EM) only creates event handlers for these types of objects. The sequential number for each application object type within a business process type should always be different and should follow in an ascending order, so that the processing order is clear. The application object ID is the technical key between the application object and the event handler, and, together with the application object type and the application system name, it forms the unique identification between the application object and the event handler.

Event Types

The application system evaluates your defined conditions and functions. It uses the evaluation results to determine whether the change to an application object requires an event to be sent to the relevant event handler in SAP EM. The sequential number for each event type within a business process type should be different and should follow an ascending order, so that the processing order is clear.

Event Handlers (EH)

Creating a test Event Handler

Transaction: /SAPTRX/EH_CREATE Enter the mandatory data:

• AOT – Application Object Type relating to the specific instance of the BPT. e.g. Warehouse Sales Order Line Item
• BPT – Business Process Type. e.g. Sales Order
• Logical System – Where is the EH going to be created?
• Tracking ID Code set – Code relating to the tracking ID.
• Tracking ID – Identifier for that particluar EH
• Use grid functions to add the following if required:
  • Control parameters – Information on the EH used in the business process
  • Info Parameters – Additional information for reporting
  • Additional Tracking Ids – Links to other Objects

Select Create EH to create the EH

Event Messages

The message can be transferred by:

• BAPI: /SAPTRX/BAPI_EH_ADDEVENTMSG_02
• IDoc: EVMSTA
• XML
• WCL – Web Communication Layer
• RF Devices

One message can report various events.

• Event / Status: What happened and who reported it?
  • ID: Which object is affected?
  • Locations: Where did the event take place?
  • Partners: Who is involved in what function?
  • Estimated time: When will subsequent events occur?
  • Delivery status: Confirmation of detail data
  • Subsequent status: Which unplanned events might be caused?
  • Load Transfer: Where is the object loaded / unloaded to
  • Measurement Result: Confirmation of measurement results
  • Text: Text messages

Summary

SCEM is used to monitor a business process end-to-end. It can alert you when things outside of the norm occur. With it’s links in to BW and archiving you can ensure that the data is available for analysis long after it’s been removed from the system. An example of where I have used it is in the monitoring of the Sales Order -> Billing Process. i.e. A sales order is created and I create an AOT for each line item. Each AOT creats an SCEM EH for which I set up expected events for SO Line Completed, Delivery Created, Delivery Packed, Delivery PGI and Invoice Created. If any one of these events don’t happen on time then alerts are sent out. When events happen early then the expected event times are adjusted accordingly. As messages are received I update the status of the Event Handler based on the status profile. This allows you to view the EH status (through the WCL for example) very quickly and easily. The WCL is used to report these events to the users. It can also be configured to report events manually that have not been received. Anyway, that’s enough for now. In subsequent posts I will go through the motions of implementing SCEM step by step.