User Transactions

Administrator Transactions

Configuration Transactions

SAP NetWeaver BW

The following list presents a starting point for naming the custom objects that are inevitably used during a SAP Event Management solution implementation.  By adhering to these naming standards, post process go-live support will be easier to maintain.

In my first blog, I spelled out what SAP Event Management covers, what it is and what it is not. (Read here) It's now time to look at SAP EM and see where it fits in to the bigger picture.

Where does SAP EM fit in to SAP’s overall solution landscape

Over the years SAP has moved the SAP EM solution across many vertical and horizontal solutions.  Originally written as a component of the Railcar Management System, SAP EM was called Supply Chain Event Management (SCEM).  SCEM was adapted to a generic solution and became an add-on component that other solutions could use.  Also known as SAP’s Track and Trace solution, it was a part of the "Supply Chain Integrity" stack.

SAP EM now falls under the end-to-end solution of “Extended Supply Chain Insights”.  The "Extended Supply Chain Insights" solutions fall under the umbrella of “Real-Time Network Insights” which, in turn falls under the "Extended Supply Chain". Quite a mouthful…

So you can see that the main focus of SAP is to highlight it's capabilities to provide "insight" in to the Supply Chain process by providing visibility to the process status and to uncover exceptions in the process. In the 7th blog in this series I describe the progression of SAP EM and it's releases but for now we will take a look at how SAP EM relates to Document Flow (because I'm always asked about that...."

In the 1st blog of the series we discussed what SAP EM is, and the 2nd showed where it fitted in to the SAP solution stack. In this blog we discuss the differences between document flow and SAP EM. I often get asked what the difference is or I hear the following "SAP EM is just glorified document flow"...

SAP EM is often utilized in conjunction with SAP Document Flow.  Document flow shows the transactions related to the business document, as they are being created by the SAP system.  A typical document flow for an order-to-cash scenario will progress as follows: Sales Order -> Delivery -> PGI -> Billing Document -> Accounting Document.  Although SAP EM can easily provide the same view to the applicable business process using document flow, it allows for a few subtler, yet powerful differences.

Document flow only shows the transactions that have occurred and has no insight into what is about to happen, (i.e., 'The Plan'), when it is going to happen, where it will happen, or who is responsible.  SAP EM has the ability to show additional detail, the capability to monitor transactions that do not occur as intended and then react by launching corrective action.  SAP EM also provides a customizable reporting interface into the process flow detail where Document Flow does not.  This functionality is a very powerful feature of SAP EM and should be adopted as widely as possible in an SAP EM enabled solution.

Another powerful distinction is that SAP EM captures the verbiage from the event message for the event that occurred.  The promptness of a supplier initiating Advanced Ship Notifications (ASN) to a customer can also be measured.  The supplier would send an ASN to the customer that the product had shipped on time.  A Service Level Agreement (SLA) exists between the supplier and the customer for the ASN to be sent within one hour after shipment.  If the ASN was sent later than that, SAP EM would measure, not only the on-time performance for shipping the goods, but also the efficiency of sending the ASN on time.  Ensuring that all supply chain partners perform timely communication is mandatory to keep the supply chain running smoothly.  Document flow does not have the capability to handle messaging around events.  SAP EM is SAP’s intended tool for this type of functionality.

Another key difference is the fact that document flow is stationary and reactive. A user has to physically call up document flow to see what has transpired against the order. With SAP EM in place, a user could be notified immediately on the receipt of an event that would have impacted document flow. In addition, the user could be notified immediately when an event is not reported when it should have. i.e. SAP EM is a truly proactive solution to monitoring your end-to-end supply chain process.

Lastly, SAP EM allows you to easily add events to your "document flow" that are not available in SAP ECC document flow. E.g. Sales Order is on CR block, Sales Order is incomplete.

These are the key differences and although they may seem subtle, their impact on allowing you to manage your Supply Chain by exception, in a proactive manner, is huge! It's all about Time-to-Insight...

In the next blog I will dive in to the details of an event followed by the differences between an event and the message sending the event.

Marco Freischlag wrote a great article entitled “SAP Event Management – How to use Multiple Tracking IDs” (Marco Freischlag, 2013).  His article describes how to post an event using several Tracking IDs.  Until SP4 for SAP Event Management 9.0, (or by implementing OSS note 1917245), it was only possibly to post an event to a single tracking ID.

There are alternative ways to achieve the same outcome but this option is now available for architects of SAP Event Management solutions to use. The most common way is to leverage different tracking IDs across the event handlers in order to have the events post to the needed EHs. Putting together the SAP EM Interface Diagram (a part of our Reveal oVo(C) Implementation Methodology for SAP EM) is critical to the understanding of how the various EHs relate to, and interact with the different EHs. An example of the Reveal SAP EM Interface Diagram is shown below.

An example application of the functionality described in Marco’s document is summarized below for reference:

• A SAP Transportation Management freight order has several railcars assigned to it
• When the ARRIVAL event comes in for the freight order it needs to be propagated to all the associated railcars so that they, too, may receive the ARRIVAL event

            In order to achieve this, using this technique, we would send an ARRIVAL event using TRXID = <dummy value> with an entry in the 'Further References' table for each of the related railcars filling in REFID = Railcar TRXID and REFUSAGE = 'M'.

Note: If the Resource Tracking Scenario is used, consider the following SAP Note: 1930447 - Table Index for /SAPTRX/EVM_REF for Resource Tracking in order to avoid performance issues.  For the details around configuring this functionality please refer to Marco’s document.^[1]

^[1]Document: SAP EM – How to use Multiple Tracking IDs written by Marco Freischlag (11/2/2013)

In my previous blog we discussed the differences between EM and Document Flow. Now it's time to start to dive in to the details of SAP Event Management and whereas could we start, other than to describe an event?

Events can be divided into two different types (actual vs. planned), which can then be grouped into four categories. Actual Event vs. Planned Event

Two types of events (refer to Figure 1)

• Events that actually occur (actual events).  These events are typically provided externally by the systems that interface with SAP EM.  Information included on these events would be 1.) date of the event, 2.) time of the event, 3.) location of the event, and 4.) person or persons involved with the event, as well as any applicable measurements pertaining to the event.  An example of the latter would the weight or temperature of the material at goods receipt.
• Events expected to occur (these events are called planned events, expected events or milestones).  Expected Events are based on 'The Plan' of when each event in the process chain should occur.  Location, partners and statistical measurements are also part of the data on the expected event.  'The Plan' is not just time based; it is also partner, location and measurement based.

Figure 1: Types of Events

These two event types need to be compared against each other, that is, compare what actually happened against what was planned.  In order to provide a more finite comparison, the types are split into four different categories.

Regular Event (The First Oval in Figure 1)

A regular event is an event that occurred within the planned expected time interval. The planned event has an early start date time entry and a late start date time entry.  Any event received between these intervals is deemed a regular event and no exceptions are raised.

Early or Late Event (The Second Oval in Figure 1)

An early event is an event that occurred before the start date time specified in 'The Plan' for that event.  A goods receipt was planned to start at 3:00 PM and to finish at 4:00 PM but the goods receipt came in at 2:00 PM.  The event is before the specified early start time, and is labeled an early event. In most cases if a task is performed early it is not seen as an exception, but it could be.  Customers specify that they do not take deliveries before 3:00 PM, as this time is the beginning of their first shift.  If the delivery occurs at 2:00 PM, then no one is there to receive and unload the shipment. This would indeed be treated as a situation to avoid in the future and is thus an exception.

A late event is an event that occurs after the end date / time specified in 'The Plan'.  In the first example, if the goods receipt notification is received at 5:00 PM, it will be marked as a late event. Once again, the choice will be made as to whether this late event is treated as an exception or not. This option is a design choice allowing the flexibility to respond immediately to relevant exception cases.

Unexpected Event (The Third Oval in Figure 1)

An unexpected event is an occurrence that was not planned for in the normal operation of this process. An example would be any event that causes a delay (such as roadside accident).  Although not all processes experience this event there is still the need to cater for this event in the design and corresponding configuration.  An unexpected event is an occurrence that may happen but is not part of the normally planned operation.  For some processes (the tracking of returnable transport items), it is not typical to have a plan for the event and all events in the process are treated as unexpected events.

Unreported Event (The Last Oval in Figure 1)

An unreported event is an event that was expected to happen at a certain time but never did. These events are also typically treated as exceptions where subsequent processing is proposed and assigned for immediate attention, such as the Goods Issue is late in occurring according to 'The Plan'.  The responsible customer sales representative for the order is notified that there is a potential delay in the shipment to the customer allowing them to reset the customer expectation.

In my next blog I will dive in to the details behind the event and the event message and describe where the early and late values play a role.

In my last blog I discussed the different types of events that SAP EM deals with. Now it's time to delve a little deeper and look in to event messages as they relate to events. SAP EM makes the distinction between events and event messages. The difference is subtle yet very significant and compelling.

An event is the recording of "something that occurs in a certain place during a particular interval of time".   An example of an event would be a post goods issue (PGI) occurring in Warehouse A at 3:00 PM (See No. 4 in Figure 1).  A plan for the event is stored in SAP EM, and the event is measured against this plan.  'The Plan' states: ‘the PGI event should happen at Warehouse A between 2:00 PM and 4:00 PM’ (See No. 1 in Figure 1).  In this example, the event is considered a regular event.

An event message provides the detail surrounding the actual occurrence that gets recorded in SAP EM.  When the event message is received in SAP EM, it is processed using the rule set.  The status of the Event Handler is potentially updated to allow visibility of the change to others.  (See No. 7 in Figure 1).  The PGI event message was received at 5:00 PM (See No. 6 in Figure 1), telling SAP EM that the PGI event was raised at 3:00 PM.  In 'The Plan', for the event message, a rule stating that the event message needed to be received by 4:00 PM (See Nos. 2 and 3 in Figure 1).  In this example, the event itself would be on time but the event message would be late by one hour.  The last status in the Event Handler would reflect, 'PGI received late'.

Event message information can, and should, differ from the actual event detail.  The event message information may be very significant in its own right.

Capturing the date and time stamp of event messaging information allows for determination of a partner's communication compliance in the supply chain, to see if there is a delay in the sending of information (See No. 5 in Figure 1).  Exchanges between Electronic Data Interchange (EDI) partners need to have this information recorded as penalties may be incurred when messages are not delivered on time.

Figure 1: Event and Event Message Relationship Described

Note: Attachments can accompany an event (See Nos. 4 and 6 in Figure 1).  A digital signature can be recorded and attached to the Proof of Delivery event.  SAP EM will then have a record of when the POD occurred together with the business' signature on file.

The overdue monitor is a scheduled job that looks for planned event messages (See No. 3 in Figure 1) that are late according to 'The Plan'.  Once an expected event is found to be late, a rule can be configured to update the Event Handler to reflect that an event message has not been received in a timely manner.  (See No. 8 in Figure 1).

Components of an Event Message

An event message is the mechanism to report an event that has occurred.  The message consists of several parts as described below.

• The Event Code - What happened?  Delivery was packed
• Event Date, Time and Time zone– When did the actual event take place? Note: The timezone plays a critical part in SAP EM because it allows the date and time to be “normalized” against GMT. This allows events to be sorted in the sequence in which they occur no matter what the timezone was that the event occurred in. E.g. A Sales Order created at 8am in San Francisco actually happened after an event that took place at 9am in London due to the timezone difference.
• Message Date, Time and Time zone– When was the message created to communicate the details of the event? This is a very important date and time when it comes to the overdue monitor. This is the first date and time that it looks at to uncover unreported events. It makes sense to have the overdue monitor wait for when the message is expected to be received before deeming it to be overdue. E.g. We expect a supplier to ship the product at 8am in the morning but we allow them 2 hours to send us the message to tell us about the shipment. This allows for latency in the communication between the 2 parties. If you look at the order at 9am you would see that the shipment was due to leave at 8am but that you have yet to receive it. From the outside it looks like it’s late but in fact we still have another hour to wait for the message before it is in fact late. This is a very key point and a very powerful nuance of SAP EM. This piece of functionality, alone, provides all the needed information to hold your suppliers accountable for the EDI messaging service level agreements. E.g. you agree with your supplier to send the ASN within 2 hours of shipping the goods, or 24 hours for sending an EDI 855 (ORDRSP) in response to receiving an EDI 850 (ORDERS)
• Tracking ID - What objects are affected?  Delivery 0008000000, Line 000010 was packed so the Tracking ID would be set as the concatenation of these two fields, i.e., 0008000000 + 000010. If all the items of delivery are affected by the same event (e.g. PGI) then the tracking ID would be the Delivery itself without the line. Note: The tracking ID is used in conjunction with a Tracking ID Code Set. The code set gives context and ensures uniqueness of the Tracking ID. E.g. Delivery 800 is not the same as Sales Order 800.
• Location ID - Where did the event occur?  The delivery was to be packed in Location 10, in the Los Angeles Warehouse. The location ID is used in conjunction with a Location ID Code Set. The code set gives context and ensures uniqueness of the Location. E.g. Plant 800 is not the same as Port 800.
• Partner ID– Who is the carrier that will take the package to its final destination?  The Partner ID is used in conjunction with a Partner ID Code Set. The code set gives context and ensures uniqueness of the Partner. E.g. Vendor 800 is not the same as Carrier 800.
• Subsequent time adjustment - Are there changes to subsequent event timings?  New delivery date scheduled, or a completely different process behavior is to be expected. This is a very key piece of functionality. As mentioned earlier, the further down the supply chain you go, the more accurate your plan for future events become. This is the functionality that enables the change of future expectations based on the latest piece of information.
• Subsequent status adjustment– Does the current event lead to a change in status?  The rule set is typically used to perform this activity but SAP has provided this detail here to force a specific status change based on the event message data itself. This could be useful if complex logic, leveraging application system data, is needed to determine the new status of the Event Handler.
• Measurement Result - Confirmation of physical measurements results. E.g. The delivery was received at Warehouse A with a temperature of -4 degrees Celsius.
• Reason - A text message accompanying the event was used to provide more details around why the event occurred.  For the event 'Delivery Refused', a typical reason could be 'Customer not home'. Note: The reason code comes with a configurable ID that allows for easier aggregate reporting as well as “free text” to capture those obscure reasons.
• Parameters– Are there any changes to the Event Handler attributes that the event needs to communicate to SAP EM?  A Proof of Delivery (POD) event should pass in the business' signature name to the Event Handler so that the SAP EM Web UI report can give visibility to this information. Another example is to send a Delivery Create event with the delivery number as a parameter to the referenced sales order. This allows the Sales Order Event Handler to display the referencing delivery number. This number can be configured to be clickable to take the user to the corresponding Delivery Event Handler.
• Attachments– Any binary file that forms part of the event detail. E.g. The Proof of Delivery (POD) event should attach the image of the person who signed for the package.

Phew, pretty intense stuff... So let's lighten it up a little and dive in to some benefits of SAP EM. Keep an eye out for the next blog in the series covering SAP EM benefits.

In my previous blog we described the differences between events and messages and now it's time to take our new-found EM knowledge and relate it back to the advantages that SAP EM can provide.

The benefits of SAP EM are dependent on the specific challenges an organization faces. This blog describes common challenges that we face today and the 2nd part of the blog will show how SAP EM can be leveraged to address this issues.

Current challenges in today’s environment could be described as follows:

Inflexible Business Model: In today’s environment, where supply chains are evolving into networks of entities, each performing their specialized tasks, having an inflexible business model leads to inefficiencies.  Referring to Figure 1, a typical supply chain requires many entities to perform all the tasks required to move product from supplier to customer.  New suppliers and logistics companies are always entering the marketplace as well as new entities, such as innovators and outsourcing partners.  The challenge for today's company is to quickly on-board these entities, giving them visibility to your supply chain network and integrating them into their supply chain processes. Global pressure to reduce costs and increase service levels force companies to strive toward the most effective and efficient Supply Chains. Customers have a “I want it now” mentality and in order to remain competitive in this environment, companies need to whittle out every inefficiency in their supply chain. This is called “Collapsing the Supply Chain”.

How can we quickly adapt to our changing supply chain needs?

Figure 1: Business Challenges

Demand Driven Network out of sync from Supply: Supply Chain Networks are demand driven.  As demand for goods and services increases, the supply chain must readjust by increasing supply at all points in the network.

How can we keep up with demand without overextending ourselves on supply?

Globalization complexity causes uncertainty ad chaos: In today’s economy where the customer base is worldwide, and supplier's locations are less relevant, it is imperative to know how well the global supply chain network is performing.  In today's world a business must contend with different systems, different languages, different time zones, different political structures, different regulations, different currencies etc....  Many incongruities exist that must be kept in delicate balance at all times.

How do we keep it all on track?

Slow to innovate: Passion exists to reinvent and innovate.  Curiosity seeks the answer to what it will take to drive the next revenue stream or capture the next cost reduction.  As these new innovative thoughts become reality, they need to be introduced quickly into the supply chain for benefits to start being realized.  If the innovation is a new product, then time-to-market is critical.  To achieve a short turnaround time, the supply chain network must respond quickly.

How do we on-board a new idea quickly and get everyone in the chain working towards a common goal?

Limited Visibility to Process Status: When the supply chain network spans several organizations, there is limited visibility into each process’ status.  In other words, it is difficult to see what is happening inside a supply chain process as it progresses from one entity to another.  This lack of visibility leads to implementing manual process tracking and reporting capabilities as a solution, which can become very expensive.  In addition, companies may decide to buffer their inventory to ensure delivery is achieved on time.  Overstocked warehouses are inefficient and lead to a costlier inventory holding than is needed.

How is my process performing?

Long Cycle Times: There is an increasing need to collapse the supply chain - in other words, to reduce the period of time required to complete an operation.  In order to achieve this reduction, minutes, even seconds, need to be shaved off of the time to action.  Companies define 'The Plan' for a process.  Any deviation from 'The Plan' is immediately reacted upon because an alert is sent to the appropriate individual, as opposed to having the bottleneck go unnoticed until it is too late.

How long does each process take?

Poor Customer Service: What happens when a customer calls inquiring about the status of their order?  Without a complete picture of the supply chain process status, only a limited, outdated response can be offered, resulting in poor customer service.  Good customer service leads to loyal customers.  Keeping customers is a critical part of the business as it is more expensive to acquire a new customer than it is to retain an old one.  Losing repeat customers will rapidly impact a company's bottom line negatively.

Where is my product? Why is it delayed? When can I expect it to be delivered?

Resource Wastage: When the supply chain experiences an unexpected turn of events causing a delay in the delivering of goods or services at a critical point, what is the best way to react?  What if this event causes resources to waste time or material at a later part of the process?  Product is scheduled to arrive at the warehouse by 3:00 PM.  Warehouse workers will be onsite by that time to offload the material.  If the goods are delayed, there will be a shift of warehouse workers twiddling their thumbs …

If an exception happens in my supply chain, can I automatically adjust the resource planning for future activities?

Risk mitigation: When products are shipped internationally in large containers, a high probability of contraband being included in the shipments exists.  With thousands of containers being offloaded at ports around the world every day, government security agents are overwhelmed with the responsibility of monitoring who has had access to these Returnable Transport Items.  Meeting government reporting requirements and insuring the safety of citizens in the destination countries are two of the tasks best accomplished by SAP EM.  This system makes it easy for companies to show compliance at each leg of the supply chain network.  SAP EM also makes it easy to record the exact location of the Returnable Transport Item, how long it was there and who was the responsible party.

Complex reporting needs: Reporting regulations are rigid and demanding in today's world.  How can it be guaranteed that regulatory needs are being met by the reports?  In addition, with a fast moving, demand driven, global process that is constantly changing, how can it be guaranteed all partners are performing?  How is it possible to ensure that all bottlenecks are being addressed and load balancing is occurring?  How often are target expectations missed?  Do exceptions occur frequently?

Summary: A common thread runs through all the challenges listed above.

• The first common element is the ability to respond - Companies cannot easily respond to these challenges when they have inflexible business models that hinder innovation.  The bar for implementing efficient processes is high and hard to reach.  For companies to stay competitive, i.e., to be able to react on a 24/7 basis, not 8/5, becomes increasing difficult as more economies around the world join the global marketplace.
• The second common element is efficiency - With the need to move new innovations to market quickly, efficiency is key.  Additionally, achieving efficiency without sacrificing quality is essential.

Business ability to respond quickly / adapt….

How efficient can you make your process? => lower costs and time to deliver

• A third element is stability - If all the Supply Chain partners execute according to the plan, there are few unknowns in the process. If exceptions occur and we know that there is a process in place to effectively and efficiently deal with them, then we can still consider the process to be relatively stable. With a stable process in place we have the piece of mind to implement less “buffer” in to our process, thus collapsing the Supply Chain and leading to improved service levels.

In the next part of this blog we will explore how SAP EM addresses these issues....

In my previous blog I listed out the issues that face the Supply Chain. In this blog I'll go through how SAP EM can be leveraged to address these issues.

How does SAP EM address the challenges mentioned in part 1 of the blog series?

Visibility: SAP EM provides maximum visibility across the supply chain network.  This visibility allows for the detection of deviations in the demand and supply of goods and services. The various types of visibility addressed by SAP EM are:

• Process visibility provides an end-to-end view of the status of the supply chain operation. This view can be provided to all partners in the supply chain arena, showing them relevant information, as and when it occurs.
  How well are we doing now? Are there any immediate issues to address? Has an event occurred requiring rescheduling or re-resourcing?
• Asset and planning visibility gives details of asset location, availability, planning and scheduling for the process to and from each of the partners.
  Where is our product? How much is going to arrive and when? Are we going to run into issues? Do we have sufficient capacity to complete the current process?
• Reporting visibility recognizes the parameters defined in Service Level Agreements (SLA). Business goals need to be defined and then measured.  These values must be visible to all parties associated with the operation, both inside and outside the company.
  How well are we doing overall? How is Vendor A performing? What percentage of orders will be delivered on time?

Ability to Respond: Through various integrated technologies, such as the SAP Alert Framework and SAP Business Workflow, SAP EM can inform the correct party of an action that needs to be taken when an exception occurs. The correct information is forwarded to the party for action.  For example, SAP EM is tracking the task the machine performs, and the machine breaks down. When the machine fails to finish the task, the event is reported to SAP EM.  A workflow is sent to the planner that also informs the planner that this machine is currently being used in two other processes, and will be used in three additional processes about to commence.  The first two processes that are currently being worked on will be rescheduled and reassigned to another machine. The last three processes will be realigned with the new schedule.

The User Interface is a key to the success of any technical product.  SAP EM provides a simple, easy-to-use web interface for reporting and capturing events.  The alerts and workflows from these events can be sent to the user's company email inbox or remain in SAP, making the product one of the most user friendly in all of the SAP suite.  With SAP EM 9.2 we have the ability to create your own user interface for SAP Fiori.

What value do we derive from SAP EM?

• Immediate value of SAP EM is high visibility of ongoing processes in the supply chain network.
• When the process fails to perform as planned, within SAP EM, an exception raises an alert to notify the proper individuals to take action.  By promptly taking action, bottlenecks in the supply chain are resolved quickly.  Customer service is improved.
• SAP EM minimizes exposure to regulatory requirements, and analyzes processes in detail via the built-in KPIs.
• Tight integration between events and their schedules leads to proactive monitoring and less reacting to emergency situations.  When the processes are efficiently and effectively monitored, there is no need to buffer inventory for the 'just-in-case' scenario.
• Another valuable use of SAP EM is the tracking of outsourced, non-core events, being performed by third parties.  Sending these message details through SAP EM are an effective way of monitoring these events, and thereby your outsourced partners.

Visibility

Time to Action

Manage by Exception

• Most events are captured from a standard SAP transact based process: If no standard process exists, then SAP EM can fill that gap by directly capturing Events manually from within SAP EM itself.
• SAP EM performs status tracking: SAP EM uncovers process exceptions, adjusts the process status and initiates an exception handling process
• SAP EM provides visibility to vertically integrated supply chain processes.  For example, the accounts payable employees have visibility to the status of a purchase order acknowledgment and the buyer will have visibility in to an invoice receipt status.

A real life look into the benefits of SAP EM for Order-to-Cash Visibility

The following section lists the benefits received from implementing SAP EM to monitor the Order-to-Cash process.

• Status Management– At each stage in the business process, it is possible to view the real-time status.  The status of an order at the line item level is updated, in real time, to reflect changes.
  Benefits:
  • Improved customer satisfaction through better informed partners (i.e., sales representatives, customers, suppliers, etc.) knowing the current status in real time.
  • Improved customer satisfaction and more efficient customer interaction through the provision of a customer self service portal, by tapping into WIMO (Where is my order?) – single, simplified company interface to the status of an order throughout its life-cycle, delivered over various types of devices
  • Reduced CSR (Customer Service Rep) average handling time due to greater efficiency in locating the status of an order (WIMO is the one stop shop for order status)
  • Improved customer satisfaction through reducing uncertainties.  A CSR can inform a customer when certain events are scheduled to occur.
  • Fewer inbound customer phone calls to inquire on order status. Exposing the order status on the web or proactively via a text or email leads to happy informed customers who tend not to call in to the Service Center to inquire on an order status.

• Exception Management– SAP EM stores 'The Plan' for the business process (when things are supposed to happen, by whom and where) and measures 'The Plan' against the ‘actual’ values.  Exceptions to the plan are highlighted, in real-time, and can be proactively resolved whether they are exception events or delays in the expected process.
  Benefits:
  • Reduction in customer calls to answer concerns.  Real time exception management with no lead time between when the system notices the exception to when it is delivered to the appropriate individual for resolution (reduced time to action) => reduction in total cycle time. Supplier notices the exception before the customer does...
  • Improved customer satisfaction for timely, accurate communication.  SAP EM has the ability to capture exceptions around the message of an event.  For example, the PGI event at 10:00 PM says the PGI occurred at 2:00 PM ...  the PGI event occurred on time, but the message reporting this was several hours late!!! SAP EM helps drive proactive behavior, especially in receiving timely accurate data from the organizations partners. This has a direct, positive impact with the customer.
  • Reduced time to resolution through system automation of known issues.  If exceptions are well categorized and the underlying data (master and transaction) is well formed, then automatic rescheduling and notification is possible => hands off automation to correct certain exceptions.
  • Reduce CSR education effort by leveraging the tight integration between SAP Business Workflow and the SAP Alert Framework allowing easy use of the existing technologies to proactively work exceptions.

• Process Analytics– SAP EM has tight integration with SAP NetWeaver BW where comprehensive analytics can be performed showing performance of each stage of the process. By deploying SAP EM on top of SAP HANA you could leverage the power of SAP HANA analytics to display real-time process analytics.
  Benefits:
  • Improved processes by leveraging business intelligence derived from their actual execution. Departments and individuals can be measured against 'The Plan' and ultimately against their individual SLAs => bottlenecks can be identified and process deficiencies addressed.
    • Vendor scorecards can be enabled through SAP EM
    • Cycle counts are possible for each stage of the business process.
      • Process Cycle Count; Average Cycle Duration:  1.) Total Cycle, 2.) Order Create to Ready, 3.) Order Create to Delivery Create, 4.) Delivery PGI to Invoice Create;
      • Percentage On-time vs. Early vs. Late:  1.) PO Goods Receipt, 2.) Delivery PGI, 3.) Invoice Create, and 4.) Order ready.
  • Reduce uncertainty by knowing how the process is performing as opposed to guessing

• Visibility– All interested and authorized parties will have visibility to the status and attributes for their processes.
  Benefits:
  • Real Time Visibility to the status and exceptions occurring within the process => Better quality information regarding the process.
  • Faster resolution of the root cause => if issues and exceptions are more visible, there is a more prevalent drive to reduce or eliminate them.
  • Improved service levels => fewer surprises occur while the process is executing.

To summarize, SAP EM is used to monitor your processes, notify you of exceptions, allow you to adjust your process accordingly to gain efficiencies and minimize exceptions, and finally to analyze your performance to learn what is going on in order to take control of your processes.

• Monitoring takes place through a standard SAP EM web interface.
• Notification takes place through the SAP Alert Framework (with email, pager, text or fax integration) or through a SAP Business Workflow notification.
• Adjusting the process takes place through SAP Business Workflow items, activities in SAP EM or kicking off actions in other systems.
• Analyzing measures the performance in a process, and this takes place in SAP NetWeaver BW or HANA Analytics where Key Performance Indicators (KPI) can be determined

Remember that SAP EM is SAP's tool to Monitor, Notify, Adjust and Analyze Supply Chain activities...

In the next blog we will take a look at the history of the SAP EM releases...

In my last blog we highlighted the issues that SAP EM resolves and what benefits it provides. Now lets talk about how we got to SAP EM release 9.2...

SAP EM began it's journey way back in 2000 but the 1st official release was made in 2004 and that's where we will pick up the story...

SAP EM 4.x

After a few pilot implementations, SAP EM was released as a solution for Supply Chain Event Management.  This release occurred in 2004 and was part of the SAP SCM 4.0 solution.  The software came bundled with the following visibility processes: 1:) procurement, 2.) fulfillment, 3.) production malfunction, and 4.) transportation.  At the end of 2004, Release 4.1 was introduced.  This release contained the first RFID-enabled visibility operation, which was Outbound Delivery Process.

SAP EM 5.0

Release 5.0, introduced in 2006, included additional RFID enabled visibility operations which included Outbound / Inbound Delivery and Returnable Transport Item processes.  By then SAP EM provided content for Rail-car Management, Seasonal Procurement and Ocean Carrier Booking.

SAP EM 5.1

Release 5.1 was shipped in 2007.  Enterprise Service-Oriented Architecture (eSOA) functionality made its appearance for the first time.  The SAP EM functionality is being more generally used than just within SAP SCM, so additional deployment options are made available as of this release.  Add-on options for SAP ERP 6.0, SAP AII, SAP TM and SAP SNC are made available. These options allow the solutions to be enabled or configured with the SAP EM functionality without the purchase of new hardware.

SAP EM 7.x

Year 2008 saw the emergence of SAP EM 7.0 when all the modules and their names were becoming aligned.  Major effort was put in this release, which featured a new, more friendly, web user interface.

SAP EM 7.0 EHP1

SAP EM 7.0 ehp1 was made generally available in May 2011 and will be supported until the end of 2020, if an extended maintenance agreement is in place.  Two new business functions are available in this release:  1.) 'Visibility Proc. for External Transportation Mgmt System' and 'Performance-Optimized PTA and Cold Chain'.  Archiving now supports processes with extremely high data volumes.  Archived data, including Event Handler hierarchies, can be displayed on the Web UI.  Certain enhancements have been made to improve the performance of the high volume scenario.

SAP EM 9.0

SAP EM 9.0 was made available in May 2013 and will be supported until the end of 2020, if an extended maintenance agreement in place.  A Rapid Deployment Solution (RDS) has been made available for Ocean Carrier Booking and another one for ERP WM integration.  The RDS for Order Tracking and Exception Management was made available in this release.  In the item serialization space, SAP EM 9.0 enhanced compliance for secure distribution of pharmaceutical products – this revolves around regulatory reporting requirements.  Geo-Tracking using SAP Visual Business is made available in this release. The route can be tracked by a location dependent object and where the event occurred is visible.

SAP EM 9.2

SAP EM 9.2 is the latest released version as of the publication of this blog.  The original release date was November 11, 2014.  This release has a new SAP EM Fiori app and also provides an example interface for SAP Jam, SAP’s social network solution.

SAP EM 9.2 SP00 includes the following:

• Freight Order Visibility App - This transactional Fiori application gives details of SAP Transportation Management freight orders that are monitored using the SAP EM Freight Order Visibility Process
• SAP EM OData Service ‘EM_SRV’ - Used to consume data from SAP EM and to send event messages to SAP EM
• Migration from SAP Visual Business version 2.0 to 2.1

In the next blog we will go in to the details of sizing your SAP EM server.

In my last blog I walked through what was made available in each of the major SAP EM releases. Now let's take a look at what to consider when sizing an SAP EM server.

Sizing a server to handle the processing for SAP EM is important.  Potentially a large amount of data can be processed by the SAP EM system in a very short period of time.  Sizing is impacted by both business and technology components.  The number of users and number of processes covered will have an impact on the size of machine required. The SAP Standard Application Benchmarks and Scalability Tests located at http://www.sap.com/benchmark can be used to determine sizing detail.

Sizing for SAP EM needs to consider the volume of Event Handlers and event messages the system will process.  Memory is dependent on the size of the packages containing event messages. 

Areas that relate to larger volumes of disk space being utilized are:

• Archiving and deleting residence times. The larger the residence time, the larger the disk space requirement
• If logging of the Event Handler and event messages is enabled, then large amounts of data are recorded and stored, thus potentially needing terabytes of disk space...

SAP provides an event management sizing guide with the following information in a .pdf file:

• Sizing CPU and Memory
  • Assumption: 4 event messages per Event Handler
  • 4 categories of volume are covered:
    • At most 100k EHs / day: 300 SAPS (CPU) and 1GB (Memory)
    • At most 250k EHs / day: 600 SAPS (CPU) and 2GB (Memory)
    • At most 500k EHs / day: 1,250 SAPS (CPU) and 4GB (Memory)
    • At most 1,000k EHs / day: 2,500 SAPS (CPU) and 8GB (Memory)

Note: There is no consideration made on the complexity of the rule set that has an impact on processing consumed

• Sizing the disk space
  • Assumption: residence period of 1 month
  • 4 categories of volume are covered:
    • At most 30m events / yr: 70GB
    • At most 75m events / yr: 190GB
    • At most 150m events / yr: 390GB
    • At most 300m events / yr: 780GB

Note: It would be advisable to use the Reveal modified version of SAP’s Event Management Sizer spreadsheet (that covers Unicode compliance) to more accurately estimate database size.  Also take into account the application log and other large tables in to specific sizing calculations.  The sizer only takes into account the size of SAP EM related tables.

In my next blog I will discuss how I determine which type of parameter to use. i.e. A Parameter decision tree...

In my last blog we spoke about the sizing considerations to take in to account for an SAP EM server. Now let's go in to one of the most asked question in SAP Event Management - "Which type of the 4 available parameters should we use? Firstly, what are the 4 parameters that we are talking about?

1 - Info Parameter

Attribute of a trackable object stored against an EH in table /SAPTRX/EH_INFO - Stored as a name - value pair (PARAM_NAME stores the name of the parameter / attribute and PARAM_VALUE stores the actual value of the attribute. E.g. PARAM_NAME - CURRENCY and PARAM_VALUE = USD. PARAM_INDEX can be used to store different values to allow for the occurrence of multiple parameters with the same name. This parameter can be shown in the SAP EM Web UI on the Event Handler selection screen, list and Detail view.

/SAPTRX/EH_INFO

2 - Control Parameter

Attribute of a trackable object stored against an EH in table /SAPTRX/EH_CNTRL - Similarly the values are stored as name - value pairs. Notice that the only difference between these 2 parameter tables is the length of the PARAM_VALUE field. The Info parameters can be 255 in length whereas the control parameter can only be 60 in length... This parameter can be shown in the SAP EM Web UI on the Event Handler selection screen, list and Detail view.

/SAPTRX/EH_CNTRL

3 - System Parameter

Attribute of a trackable object stored against an EH in a Z table - The ONLY reason to store a parameter in a z-table (system parameter) is when it is frequently used as part of a query search to retrieve EHs. System parameters ultimately get stored in named, physical database fields that can have indexes created against them. Without an index being created for a field in the extension table renders it pretty much useless since without the applicable index the query would not be faster than if it were stored as a control or info parameter. See an example below. Notice the key is just the EH_GUID. This parameter can be shown in the SAP EM Web UI on the Event Handler selection screen, list and Detail view.

Note: A view called ZV_[system parameter name] is created as a join between /SAPTRX/EH_HDR and your system parameter table.

Z Table with defined field for each parameter

4 - Event Message Parameter

Attribute applicable to a particular instance of an event. It describes a certain characteristic specific to the event that is attached to the EVT_GUID (The unique ID for that event). It typically should not be stored against the EH because it only applies to that one event. This parameter can be shown in the SAP EM Web UI on the Event Message list and Detail view. Note: The key to the z table that stores the event message parameter is the Event GUID. Its intended use is drastically different from the extension table of the EH. The EH extension table is used to improve performance of queries whereas the event message extension table is used to store extra data describing the event that it is associated with.

Z table with defined fields for each message parameter

Now it comes down to decision time - Decision Tree

A decision must be made on which parameter type to use for each attribute of an Event Handler or Event Message.  For performance reasons, it is best to split values between the info and control parameter tables. Below is an example of a decision tree used to decide on the parameter type:

I don't think I need to go through all the words in the tree - Hopefully it's self explanatory and is useful to you. Please leave a comment if you have other ideas or inputs for this decision tree that I use.

In my next blog I'll take a look at the available web services in SAP Event Management. Come back and take a peak soon...

In my previous blog I hit on the hot topic of parameters and which ones should I use where... Check it out here.

Now let's get in to a little nerd stuff Web Services... This blog is intended to give you the quick links to go find the necessary detail to describe each of the available services. The documentation can be rather hard to find.... until now...

SAP EM web services can be found on the SAP Community Network or on the SAP help portal.

ProcessTracking

• Software Component Version:     ESM SCEMSRV 7.01
• Technical Name:     ProcessTracking
• Namespace:     http://sap.com/xi/ESM/SCEMSRV

Applicable Business Objects: SAP EM provides two business objects for tracking using Web Services:

• Tracked Process– an Event Handler
• Tracked Process Event Notification– an event message

Available Web Service Interfaces: Six service interfaces are available:

1. Manage Tracked Process In - receives contents of a tracked process.

    Operations:

• Read Tracked Process - reads contents of a specific tracked process; returns track-ing IDs, parameters, measurements, statuses and events.

i.    Technical Name:     TrackedProcessByIDQueryResponse_In

ii.    Namespace:         http://sap.com/xi/EM/Global

iii.    SAP Defn:             /SAPTRX/TRACKEDPROCESSBYIDQUER

iv.    Direction:             Inbound

v.    Mode:             Synchronous

vi.    Available BAdI:     Retrieve Event Handler (/SAPTRX/SE_EH_RETRIEVAL)

vii.    Message Types:

1.    TrackedProcessByIDQueryMessage_sync

2.    TrackedProcessByIDResponse_sync

3.    Query Tracked Process In - receives results of a tracked process search.

• Find Tracked Process by elements– finds a tracked process according to specific criteria

i.    Technical Name:     TrackedProcessSimpleByElementsQueryResponse_In

ii.    Namespace:         http://sap.com/xi/EM/Global

iii.    SAP Defn:         /SAPTRX/TRACKEDPROCESSSIMPLEBY

iv.    Direction:         Inbound

v.    Mode:             Synchronous

vi.    Available BAdI:     Query Event Handler         (/SAPTRX/SE_EH_QUERY)

vii.    Message Types:

1.    TrackedProcessSimpleByElementsQueryMessage_sync

2.    TrackedProcessSimpleByElementsResponseMessage_sync

3.    Tracked Process Event Notification Processing In - requests the crea-tion of a tracked process event notification (creates an event)

• Create Tracked Process Event Notification - creates a tracked process event notification.

i.    Technical Name: TrackedProcessEventNotificationCreateRequest_In

ii.    Namespace:     http://sap.com/xi/EM/Global

iii.    Direction:         Inbound

iv.    Mode:             Asynchronous

v.    Available BAdI:     Event Handler (create, update, delete)     /SAPTRX/SE_EH_CRE_UPD_ DEL

vi.    Message Types:

1.    Tracked Process Event Notification Create Request

2.    Tracked Process Event Notification Processing Out - sends confirma-tion of the creation of a tracked process event notification.

• Confirm Creation Tracked Process Event Notification - confirms the creation of a tracked process event notification.

i.    Technical Name:        TrackedProcessEventNotificationCreateConfirmation_Out

ii.    Namespace:         http://sap.com/xi/EM/Global

iii.    Direction:         Outbound

iv.    Mode:             Asynchronous

v.    Message Types:   

1.    Tracked Process Event Notification Create Confirmation

2.    Tracked Process Processing In - requests the creation or change of a tracked process.

• Maintain Tracked Process - request to create a new tracked process or update an existing tracked process

i.    Technical Name:     TrackedProcessRequest_In

ii.    Namespace:         http://sap.com/xi/EM/Global

iii.    Direction:            Inbound

iv.    Mode:             Asynchronous

v.    Available BAdI:    Event Handler (create, update, delete) /SAPTRX/SE_EH_CRE_UPD_DEL

vi.    Message Types:

1.    Tracked Process Request

2.    Tracked Process Processing Out – sends confirmation of the creation of a tracked process.

• Confirm Tracked Process– confirms a request to create, change or delete a tracked process.

i.    Technical Name:     TrackedProcessConfirmation_Out

ii.    Namespace:         http://sap.com/xi/EM/Global

iii.    Direction:         Outbound

iv.    Mode:             Asynchronous

v.    Message Types:    TrackedProcessConfirmation

In my next installment of the SAP EM blog series we will run through some troubleshooting tips... Should be fun.

In my last blog we described the various Web Services that you can use to interact with SAP Event Management. Now let's look in to SAP EM troubleshooting and providing some tips. Please feel free to add your own comments to keep a running list of tips and tricks...

On the Application System

If the Event Handler or Event message fails to reach the SAP EM system what steps should you take?

1. Check messages issued during Application Object creation and Event creation. You should see a count of relevant objects being sent to SAP EM that corresponds to your expectation. (Transaction: /SAPTRX/ASAPLOG)
2. Check for any RFCs stuck in the outbound qRFC queue (Transaction: SMQ1) - The queue name is typically EM_<BPT> where <BPT> is the applicable business process type. If the status is “SYSFAIL” then check short dumps in SAP EM (Transaction: ST22)
3. Check that the QOUT Scheduler is Registered for the SAP EM Destination (Transaction: SMQS)
4. Check for any short dump entries (Transaction: SM21 / ST22)
5. Check for any stuck transactional RFCs (Transaction: SM58)
6. Check that the QIN Scheduler is Registered (Transaction: SMQR)
7. Check for any RFCs stuck in the inbound qRFC queue (Transaction: SMQ2) – This queue is used to process the inbound acknowledgement to table /SAPTRX/AOTREF - The queue name is typically EM<GUID> where <GUID> is the corresponding EH GUID from SAP EM

On the SAP EM System

If the Event Handler or Event message fails to post in SAP EM system what steps should you take?

1. Determine if the Event or Event Handler arrived using one of these reports
   1. Event Handler List (Transaction: /SAPTRX/EH_LIST)
   2. Last Report Event List (Transaction: /SAPTRX/EH_LAST_EVT)
   3. Event Message Processing Error List (Transaction: /SAPTRX/ER_MS_LIST)
   4. The Event Message processing list (Transaction: /SAPTRX/EVM_STATUS)
2. Check the SAP EM relevant jobs are running (Transaction: /SAPTRX/EMJOBS)
   1. Manually run the locked EH and EHS reports (Transaction: /SAPTRX/LOCKED_PROC and Transaction: /SAPTRX/LOCKED_PSET)
3. Check the Application Log for any messages issued there (Transaction: SLG1)
4. Check the system log for ABAP dumps (Transaction: SM21 / ST22)
5. Check the RFC trace log for RFC issues (Transaction: SM59 on the application system)
6. Check for locked EHs in table /SAPTRX/LOCKEDEH. Run the locked EH job (/SAPTRX/PROCESS_LOCKED_EH) to ensure that all events have been posted
7. Check table /SAPTRX/RP_AOID for entries. It stores the application object IDs that could not be posted due to locking issues. Run job /SAPTRX/R_REPOST_AI_LOGS to re-post the data accordingly.
8. If no EH has been created, then also check these 2 settings:
   1. EH Type condition– Make sure that it is defined to your requirement
   2. The applicable Parameter Mapping profile is created and assigned to the application system sending the object for tracking
9. If the Event Message was received but did not post correctly, then Reprocess Messages in Simulation mode to determine where the issue lies
10. Lastly, check table /SAPTRX/EH_HDR for new Event Handlers and work back from there to find out what went wrong.
    1. See if the message made it to table /SAPTRX/EH_EVMSG– If it is in this table but is marked as irrelevant then check that the event code has been registered as an acceptable unexpected event in the EH type definition
    2. For Event Messages gone missing check table /SAPTRX/EVM_HDR and work back from there to find out what went wrong

Please feel free to comment on this procedure and add to it... Thank you.

In the 1st blog of this series I described what SAP EM is and in the 6th one I described, in 2 parts, what the challenges and benefits are that are associated with SAP EM. I want to take that a little deeper and relate it directly to the order to cash process.

What is covered in an order to cash process? For simplicity sake I will address a simple scenario where an order is taken and fulfilled out of a warehouse. Similar discussions and benefits can be described for orders being fulfilled via drop-ship or via a manufacturing process.

So, what are we talking about in terms of the process?

1) The Sales Order representing a customer's demand for a particular product. It reflects the price the customer is on the hook for the order. It also states what the product is, the quantity needed and the location that it should be shipped to. Lastly, and probably most importantly, when the customer can expect the product to be shipped and ultimately delivered. PS: There are naturally many more aspects to a Sales Order but these are the key attributes that we will focus on.

2) The Delivery representing the document that is used by the warehouse to manage the process of picking the applicable product from the bins in the warehouse in order to pack them in a box to be shipped to the customer. The key information that we need to track here is the location of the warehouse, the location of the customer, the carrier that has been selected to transport the goods, the carrier's tracking number (or numbers), the packing information (what's in the boxes) and last, but not least, the date that it left the warehouse. PS: Again, there are many, many more aspects to a delivery but these are the components that are of most interest to up-stream and down-stream processes. i.e. The customer service rep is interested in this information just as much as the actual end customer.

3) The Invoice representing the document that is used by the Accounts Receivable department to collect the money from the customer for the order that was placed. The key information here is when the invoice was created, where it was sent to, what the payment terms are, when payment can be expected and any applicable discounts and charges that were associated with the order.

That's a 10,000 foot view of the OTC process for a warehouse fulfilled Sales Order: Order -> Delivery -> Invoice. Now let's see how SAP EM plays a role in monitoring and managing this process...

SAP Event Management (EM) is a tool provided for, by SAP, to help you manage your business processes (any business process) by exception. Listed below are the main aspects of SAP EM that are beneficial within the OTC process, together with a description of the potential benefit for each point.

• Status Management– At each stage in the process, at an instance level, you are easily able to view the real-time status of your business process. The status of the Sales Order (at a line item level) is updated in real time to reflect its change in status. The status reflects a change in disposition of the applicable document in the OTC process and these are shown in detail below.

Sales Order:

Typical changes that we track for a Sales Order include:

1. Sales Order was placed on a delivery block <-> Sales Order was taken off a delivery block
2. Sales Order was placed on a CR block <-> Sales Order was taken off a CR block
3. Sales Order is incomplete (it still needs some information in order to be processed further) <-> Sales Order has all the needed information to proceed
4. Sales Order is ready for fulfillment

Things that SAP EM monitors at this stage of the process include:

1. Is the Service Level Agreement (SLA) being upheld to ensure a delivery block is removed in the agreed time?
2. Is the SLA being upheld to ensure a CR block is removed in the agreed time?
3. Is the SLA being upheld to ensure the in-completion reasons are removed in the agreed time?
4. Is the delivery going to be created in time in order to still deliver to the customer as promised?

Delivery:

Typical changes that we track for a Delivery include:

1. Delivery has been created against a Sales Order
2. Delivery has been picked and Packed
3. Delivery has been Shipped out of the warehouse

Things that SAP EM monitors at this stage of the process include:

1. Is the Service Level Agreement (SLA) being upheld to ensure the delivery is created on time?
2. Is the SLA being upheld to ensure the delivery is picked and packed in the agreed time?
3. Is the SLA being upheld to ensure the delivery ships out of the warehouse on the agreed date?
4. Is the customer still going to receive their product on the promised delivery date?

Invoice:

Typical changes that we track for an Invoice include:

1. Invoice has been created against a Sales Order or Delivery
2. Invoice has been sent to the customer
3. Invoice has been paid in full

Things that SAP EM monitors at this stage of the process include:

1. Is the Service Level Agreement (SLA) being upheld to ensure the invoice is created on time?
2. Is the SLA being upheld to ensure the invoice is being paid in the agreed time? i.e. within payment terms

The benefits attributable to knowing the status at each step of the OTC process includes the following:

1. Improved customer satisfaction through informed partners (Sales Reps and customers) knowing the current status in real time. If, at any time in the process, an SLA is missed or the agreed on ship or delivery date are adjusted, the customer can immediately be informed.
2. Improved customer satisfaction and reduced customer touches through the provision of the real-time Sales Order status to the customer via a web portal (other mechanisms to expose the status to a customer are also available e.g. Web Service)
3. Reduced Sales Rep average handle time due to a reduction in effort to locate the status of an order (SAP EM is the one stop shop for Sales Order status)
4. Improved customer satisfaction through reducing uncertainties in the process. A CSR can inform a customer as to when certain events, that have not yet occurred, are planned to occur.

• Exception Management– Since SAP EM stores the “plan” for your business process (when things are supposed to happen, by who, at what place) and can measure it against the “actual”, the exceptions to the plan are highlighted, in real time, and can be proactively worked to resolution. This includes exception events or delays in the expected process.

Sales Order:

Typical changes that we track for a Sales Order include:

1. Sales Order was placed on a delivery block
2. Sales Order was placed on a CR block
3. Sales Order is incomplete (it still needs some information in order to be processed further)
4. Sales Order has been cancelled (An exception)

SAP EM is leveraged to manage by exception at this stage of the process as follows:

1. As a CSR show me all the orders, that I am responsible for, that are on a delivery block so that I may address them
2. As a CR rep show me all the orders, that I am responsible for, that are on a CR block so that I may address them
3. As a CSR show me all the orders, that I am responsible for, that have missing data so that I may address them

Delivery:

Typical changes that we track for a Delivery include:

1. Sales Orders where a delivery has yet to be created (yet should have been according to the schedule line of the order)
2. Delivery date has been adjusted to a different date that does not meet the customers promised delivery date
3. Delivery has yet to ship, yet it was due to ship
4. Delivery shipped late

SAP EM is leveraged to manage by exception at this stage of the process as follows:

1. As a CSR show me all the orders, where the delivery has yet to be created, but should have been, so that I may address them
2. As a CSR show me all the orders, that I am responsible for, where the delivery date differs to what was promised to the customer, so that I may address them
3. As a CSR show me all the orders, that I am responsible for, where the delivery has yet to ship but should have, so that I may address them
4. As a CSR show me all the orders, that I am responsible for, where the delivery shipped late, so that I may address them

Invoice:

Typical changes that we track for an Invoice include:

1. Invoice has yet to be created but should have
2. Invoice was created late
3. Invoice has yet to be paid in full and is outside terms
4. Invoice has been cancelled (An exception)

SAP EM is leveraged to manage by exception at this stage of the process as follows:

1. As a CSR show me all the orders, where the invoice has yet to be created, but should have been, so that I may address them
2. As a CSR show me all the orders, where the invoice should have been paid, but no payment has been received, so that I may address them

The benefits attributable to knowing the status at each step of the OTC process includes the following:

1. Improved customer satisfaction and reduction in customer calls to query issues. Real time exception management with no lead time between when the system notices the exception to when it is delivered to the applicable person for resolution (reduced time to action) => reduction in total cycle time. You notice the exception before the customer does… In the end the goal is to only work the true exceptions in your business process.
2. Improved customer satisfaction and reduction in customer calls to query issues. Due to the ability to capture all exceptions whereas previously only transaction exceptions were possible. SAP EM has the ability to capture exceptions around the message of an event. E.g. We can receive a delivery PGI event at 10PM telling us that the PGI occurred at 2PM… well the PGI event occurred on time but the message telling us about this was several hours late!!! (See my blog on the distinction between messages and events)
3. Reduced time to resolution through system automation of known issues. If exceptions are well categorized and the underlying data (master and transaction) is well formed then automatic rescheduling and notification is possible => hands off automation to correct certain exceptions.
4. Reduce CSR education effort by leveraging the tight integration with workflow and the alert framework allowing you to easily embrace existing technologies to proactively work exceptions

• Process Analytics– SAP EM has tight integration built in with SAP NetWeaver BW where comprehensive analytics can be performed showing how each stage of your process is performing. In addition SAP EM is now available on the SAP HANA stack so you also have the ability to leverage SAP HANA anayltics to access Real-Time analytics for your OTC process.

Benefits:

1. Improved processes through leveraging business intelligence gained from knowledge of the process. Departments and partners can be measured against the “plan” and also ultimately against their individual SLAs => Can highlight and identify bottlenecks and address process deficiencies.
   1. Scorecards (How is each department performing against their individual SLA?) can be enabled through SAP EM
   2. Cycle counts are possible for each stage of the business process.
      1. E.g. Process cycle count, Average cycle duration: Total cycle, Order create to ready for fulfillment, Order create to delivery create, Delivery Shipped to Invoice create. Also % on time vs. early vs. late: Delivery Shipped, Invoice create, Sales Order ready for fulfillment.
2. Reduce uncertainty by knowing how your process is performing as opposed to guessing

• Visibility– All interested and authorized parties will have visibility to the status and attributes for their processes.

Benefits:

1. Real Time Visibility to the status and exceptions occurring within your process => Better quality information regarding your process.
2. Faster resolution of the root cause because if issues and exceptions are more visible then the drive to reduce or eliminate them is more prevalent.
3. Improved service levels through fewer surprises occurring throughout the process

If you have experience in implementing this scenario please feel to share your thoughts. Thank you

Kevin

Or how can I enhance my Fiori Application?

Hi,

After the blog The ultimate Step by Step Guide for Wizardry generated a full Fiori Application based on ODT40, I'll now show you how to enhance your Report Expected Event Dialog to report EventReasonText as well in less than 5 Minutes™!

Disclaimer:

This guide does not help with making cookies.

Presets:

• Working Web IDE
• Working Fiori Event Managment Application

Step one - Identify your enhancing point

In your Fiori Application under the "fragments" Folder you will find the "ReportDialog.fragment.xml". This fragment describes the dialog that will popup once you press the Pencilbutton inside the Eventmessagetable.

Step two - Commencing Enhancing

Its a pretty straight forward way to include a label and an input into the dialog. The Syntax is xml so its even readable:

The text for the label is already in place in the OdataService. Every Property in the EventMessageOverview Collection can be used directly without defining your own labeltext!

The Input just needs the changemethod and the Customdata and your almost ready to go!

Step two - Fixing the logic

We need to provide only a small fix for the logic in order to make it work. Navigate to your Details.controller:

And comment the following line, just like in my example picture:

Step three - Let the magic happen

Voila. Or Voilá? That french word for "tadaa"! We have a Fiori Application that can report reason for expected events:

There you go! An enhancement in less than 5 Minutes!

Scenario

The standard SAP EM overdue list /SAPTRX/EE_OVD_LIST does not support creating it in the background. This report generates a spool list. In the job that creates the spool list we maintain the distribution list to email it to the recipients.

Maintaining a distribution list

Maintain a shared distribution list using transaction SO23

Creating the job

Create a job using transaction SM36 with step ZSAPTRX_EE_OVERDUE_LIST and Spool list recipient being the distribution list created above.

Report

The report below was copied from /SAPTRX/EE_OVD_LIST and modified to work in the backround.

Selection Texts

• P_AO_ID          Application object ID
• P_AO_SYS       Application system
• P_AO_TP          Application Object Type
• P_EVCODE      Event internal code
• P_EVGRP         Event code group
• P_EVTDAT       Expected event date
• P_MSGDAT      Expected message date
• P_PARCS         Partner ID Codeset (Sender)
• P_PARID          Partner ID (Sender)
• P_TRID             Tracking ID
• P_TRIDTP         Tracking ID codeset
• P_TROBTP       Business process type
• P_TRTP            Event handler type
• P_VARI             Report Display Variant
• S_LBL              Participation Label
• S_MATNR         Material Number
• S_MRPCRL       MRP Controller
• S_PLANT          Plant
• S_PLNDTE       PO Planned Delivery Date
• S_PONUM        PO Number
• S_POORG        Purchasing Organization
• S_POTYP         PO Type
• S_VNDNO        Vendor Number

Text Symbols

• 001                   Event handler
• 002                   Expected event
• 011                   Appl obj type
• 013                   Appl System
• 014                   Appl obj ID
• 015                   Track ID Codeset
• 016                   Tracking ID
• 017                   PO NUMBER
• 018                   PO LINE
• 019                   Material
• 020                   Material
• 021                   PLANT
• 022                   PO TYPE
• 023                   PO ORG
• 024                   MRP CTL
• 025                   Planned Deliv Dt
• 026                   Vendor
• 027                   Vendor Name
• 028                   Overdue Days
• T01                   Variant for Report
• T02                   Display variant
• T03                   Report Display Variant
• T04                   Parameter Selections

ABAP Code

*&---------------------------------------------------------------------*

*& Report ZSAPTRX_EE_OVERDUE_LIST                                     *

*&---------------------------------------------------------------------*

REPORT  ZSAPTRX_EE_OVERDUE_LIST.

TYPE-POOLS: sscr, slis.

TABLES: /saptrx/eh_hdr,

        /saptrx/eh_expev.

CONSTANTS: c_true     VALUE 'X',

            report     TYPE rsvar-report VALUE 'ZSAPTRX_EE_OVERDUE_LIST'.

DATA: variante        LIKE disvariant,          

      def_variante    LIKE disvariant,          

      variant_exit(1) TYPE c,

      variant_save(1) TYPE c,
alv_default_variant    LIKE disvariant-variant,

      layout          TYPE slis_layout_alv,

      fieldcat        TYPE slis_t_fieldcat_alv,

      gs_layout       TYPE lvc_s_layo,

      gs_var_layout   TYPE disvariant,

      ls_fieldcat     TYPE slis_fieldcat_alv,

      lt_fieldcat     TYPE slis_t_fieldcat_alv,

      wa_fieldcat1    TYPE LINE OF slis_t_fieldcat_alv.

TYPES: BEGIN OF to_ex_ev,

         ao_system       LIKE /saptrx/eh_hdr-ao_system,

         ao_type         LIKE /saptrx/eh_hdr-ao_type,

         ao_id           LIKE /saptrx/eh_hdr-ao_id,

         trackingidtype  LIKE /saptrx/eh_hdr-trackingidtype,

         trackingid      LIKE /saptrx/eh_hdr-trackingid.

        INCLUDE STRUCTURE /saptrx/eh_expev_dyn.

TYPES:   po_number(10)   TYPE n,

         po_line(6)      TYPE n,

         matnr(10)       TYPE c,

         matx(33)        TYPE c,

         plant(4)        TYPE c,

         po_type(4)      TYPE c,

         po_org(4)       TYPE c,

         mrp_cntrl(3)    TYPE c,

         po_pln_dte      TYPE sy-datum,

         vendor_no(10)   TYPE c,

         vendor_name(20) TYPE c,

         overdue_days(5) type n,

po_item_qty(10)    type p decimals 0,

         po_gr_qty(10)      type p decimals 0,

         po_gr_diff(10)     type p decimals 0,

         par_lbl(11)   type c.

TYPES: END OF to_ex_ev.

INITIALIZATION.

  variant_save = 'A'.

  CLEAR variante.

  variante-report = sy-repid.

  def_variante = variante.

  CALL FUNCTION 'REUSE_ALV_VARIANT_DEFAULT_GET'

    EXPORTING

      i_save     = variant_save

    CHANGING

      cs_variant = def_variante

    EXCEPTIONS

      not_found  = 2.

  IF sy-subrc = 0.

    MOVE  def_variante-variant  TO alv_default_variant.

    p_vari = def_variante-variant.

  ENDIF.

AT SELECTION-SCREEN.

  IF NOT p_vari IS INITIAL.

    MOVE variante TO def_variante.

    MOVE p_vari TO def_variante-variant.

    CALL FUNCTION 'REUSE_ALV_VARIANT_EXISTENCE'

      EXPORTING

        i_save     = variant_save

      CHANGING

        cs_variant = def_variante.

    variante = def_variante.

  ELSE.

    CLEAR variante.

    variante-report = sy-repid.

  ENDIF.

AT SELECTION-SCREEN ON VALUE-REQUEST FOR p_vari.

  PERFORM f4_for_variant.

START-OF-SELECTION.

  PERFORM get_data.

  IF g_exp_ev IS INITIAL.

    MESSAGE i252(aq).  " no records found

    EXIT.

  ENDIF.

END-OF-SELECTION.

*** Main Program

  PERFORM build_fieldcatalog.

  gs_layout-no_hgridln = c_true.

  gs_var_layout-report = report.

  CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY'

      EXPORTING

           i_callback_program       = v_pgm

           i_callback_pf_status_set = 'STATUS'

           i_callback_user_command  = 'USER_COMMAND'

           is_layout                = layout

           it_fieldcat              = lt_fieldcat[]

           i_default                = 'X'

           i_save                   = 'A'              

           is_variant               = variante         

      TABLES

           t_outtab                 = g_exp_ev

           EXCEPTIONS

           OTHERS                   = 2.

  IF  NOT sy-subrc IS INITIAL.        

    MESSAGE ID sy-msgid TYPE  'S'     NUMBER sy-msgno

            WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.

  ENDIF.

*&---------------------------------------------------------------------*

*&      Module  pbo OUTPUT

*&---------------------------------------------------------------------*

FORM build_fieldcatalog.

  DATA: BEGIN OF l_cols OCCURS 14,

           col_name LIKE ls_fieldcat-fieldname,

           position LIKE ls_fieldcat-col_pos,

        END OF l_cols,

        l_col       LIKE LINE OF l_cols.

  l_cols-col_name = 'EVENT_CODE'.

  l_cols-position = 6.                  APPEND l_cols.

  l_cols-col_name = 'MSG_EXP_DATE'.

  l_cols-position = 7.                  APPEND l_cols.

  l_cols-col_name = 'LATEST_MSG_DATE'.

  l_cols-position = 8.                  APPEND l_cols.

  l_cols-col_name = 'MSG_RCVD_DATE'.

  l_cols-position = 9.                  APPEND l_cols.

  l_cols-col_name = 'EVENT_EXP_DATE'.

  l_cols-position = 10.                 APPEND l_cols.

  l_cols-col_name = 'EVENT_DATE'.

  l_cols-position = 11.                 APPEND l_cols.

  l_cols-col_name = 'LATEST_EV_DATE'.

  l_cols-position = 12.                 APPEND l_cols.

  l_cols-col_name = 'PARTNER_ID_TYPE'.

  l_cols-position = 13.                 APPEND l_cols.

  l_cols-col_name = 'PARTNER_ID'.

  l_cols-position = 14.                 APPEND l_cols.

  l_cols-col_name = 'LOC_ID_TYPE'.

  l_cols-position = 15.                 APPEND l_cols.

  l_cols-col_name = 'LOC_ID_1'.

  l_cols-position = 16.                 APPEND l_cols.

  l_cols-col_name = 'MSG_STATUS'.

  l_cols-position = 17.                 APPEND l_cols.

  ls_fieldcat-fieldname  = 'AO_TYPE'.

  ls_fieldcat-inttype    = 'C'.

  ls_fieldcat-reptext_ddic    = 'Appl obj type' (011).

  ls_fieldcat-intlen     = 4.

  ls_fieldcat-outputlen  = 4.

  ls_fieldcat-col_pos    = 2.

  APPEND ls_fieldcat TO lt_fieldcat.

  CLEAR ls_fieldcat.

  ls_fieldcat-fieldname  = 'AO_ID'.

  ls_fieldcat-col_pos    = 3.

  ls_fieldcat-inttype    = 'C'.

  ls_fieldcat-reptext_ddic    = 'Appl obj ID' (014).

  ls_fieldcat-intlen     = 30.

  ls_fieldcat-outputlen  = 12.

  APPEND ls_fieldcat TO lt_fieldcat.

  CLEAR ls_fieldcat.

  ls_fieldcat-fieldname  = 'AO_SYSTEM'.

  ls_fieldcat-col_pos    = 1.

  ls_fieldcat-inttype    = 'C'.

  ls_fieldcat-reptext_ddic    = 'Appl System'(013).

  ls_fieldcat-intlen     = 30.

  ls_fieldcat-outputlen  = 12.

  APPEND ls_fieldcat TO lt_fieldcat.

  CLEAR ls_fieldcat.

  ls_fieldcat-fieldname  = 'TRACKINGIDTYPE'.

  ls_fieldcat-inttype    = 'C'.

  ls_fieldcat-reptext_ddic    = 'Track ID Codeset'(015).

  ls_fieldcat-intlen     = 20.

  ls_fieldcat-outputlen  = 10.

  ls_fieldcat-col_pos    = 4.

  APPEND ls_fieldcat TO lt_fieldcat.

  CLEAR ls_fieldcat.

  ls_fieldcat-fieldname  = 'TRACKINGID'.

  ls_fieldcat-inttype    = 'C'.

  ls_fieldcat-reptext_ddic    = 'Tracking ID'(016).

  ls_fieldcat-intlen     = 50.

  ls_fieldcat-outputlen  = 20.

  ls_fieldcat-col_pos    = 5.

  APPEND ls_fieldcat TO lt_fieldcat.

  CLEAR ls_fieldcat.

  ls_fieldcat-fieldname  = 'PO_NUMBER'.

  ls_fieldcat-inttype    = 'C'.

  ls_fieldcat-reptext_ddic    = 'PO NUMBER'(017).

  ls_fieldcat-intlen     = 10.

  ls_fieldcat-outputlen  = 10.

  ls_fieldcat-col_pos    = 18.

  APPEND ls_fieldcat TO lt_fieldcat.

  CLEAR ls_fieldcat.

  ls_fieldcat-fieldname  = 'PO_LINE'.

  ls_fieldcat-inttype    = 'C'.

  ls_fieldcat-reptext_ddic    = 'PO LINE'(018).

  ls_fieldcat-intlen     = 7.

  ls_fieldcat-outputlen  = 7.

  ls_fieldcat-col_pos    = 19.

  APPEND ls_fieldcat TO lt_fieldcat.

  CLEAR ls_fieldcat.

  ls_fieldcat-fieldname  = 'MATNR'.

  ls_fieldcat-inttype    = 'C'.

  ls_fieldcat-reptext_ddic    = 'Material'(019).

  ls_fieldcat-intlen     = 10.

  ls_fieldcat-outputlen  = 10.

  ls_fieldcat-col_pos    = 20.

  APPEND ls_fieldcat TO lt_fieldcat.

  CLEAR ls_fieldcat.

  ls_fieldcat-fieldname  = 'MATX'.

  ls_fieldcat-inttype    = 'C'.

  ls_fieldcat-reptext_ddic    = 'Material'(020).

  ls_fieldcat-intlen     = 33.

  ls_fieldcat-outputlen  = 33.

  ls_fieldcat-col_pos    = 21.

  APPEND ls_fieldcat TO lt_fieldcat.

  CLEAR ls_fieldcat.

  ls_fieldcat-fieldname  = 'PLANT'.

  ls_fieldcat-inttype    = 'C'.

  ls_fieldcat-reptext_ddic    = 'PLANT'(021).

  ls_fieldcat-intlen     = 4.

  ls_fieldcat-outputlen  = 4.

  ls_fieldcat-col_pos    = 22.

  APPEND ls_fieldcat TO lt_fieldcat.

  CLEAR ls_fieldcat.

  ls_fieldcat-fieldname  = 'PO_TYPE'.

  ls_fieldcat-inttype    = 'C'.

  ls_fieldcat-reptext_ddic    = 'PO TYPE'(022).

  ls_fieldcat-intlen     = 4.

  ls_fieldcat-outputlen  = 4.

  ls_fieldcat-col_pos    = 23.

  APPEND ls_fieldcat TO lt_fieldcat.

  CLEAR ls_fieldcat.

  ls_fieldcat-fieldname  = 'PO_ORG'.

  ls_fieldcat-inttype    = 'C'.

  ls_fieldcat-reptext_ddic    = 'PO ORG'(023).

  ls_fieldcat-intlen     = 4.

  ls_fieldcat-outputlen  = 4.

  ls_fieldcat-col_pos    = 24.

  APPEND ls_fieldcat TO lt_fieldcat.

  CLEAR ls_fieldcat.

  ls_fieldcat-fieldname  = 'MRP_CNTRL'.

  ls_fieldcat-inttype    = 'C'.

  ls_fieldcat-reptext_ddic    = 'MRP CTL'(024).

  ls_fieldcat-intlen     = 3.

  ls_fieldcat-outputlen  = 3.

  ls_fieldcat-col_pos    = 25.

  APPEND ls_fieldcat TO lt_fieldcat.

  CLEAR ls_fieldcat.

  ls_fieldcat-fieldname  = 'PO_PLN_DTE'.

  ls_fieldcat-inttype    = 'D'.

  ls_fieldcat-reptext_ddic    = 'Planned Deliv Dte'(025).

  ls_fieldcat-intlen     = 8.

  ls_fieldcat-outputlen  = 8.

  ls_fieldcat-col_pos    = 26.

  APPEND ls_fieldcat TO lt_fieldcat.

  CLEAR ls_fieldcat.

  ls_fieldcat-fieldname  = 'VENDOR_NO'.

  ls_fieldcat-inttype    = 'C'.

  ls_fieldcat-reptext_ddic    = 'Vendor'(026).

  ls_fieldcat-intlen     = 10.

  ls_fieldcat-outputlen  = 10.

  ls_fieldcat-col_pos    = 27.

  APPEND ls_fieldcat TO lt_fieldcat.

  CLEAR ls_fieldcat.

  ls_fieldcat-fieldname  = 'VENDOR_NAME'.

  ls_fieldcat-inttype    = 'C'.

  ls_fieldcat-reptext_ddic    = 'Vendor Name'(027).

  ls_fieldcat-intlen     = 20.

  ls_fieldcat-outputlen  = 20.

  ls_fieldcat-col_pos    = 28.

  APPEND ls_fieldcat TO lt_fieldcat.

  CLEAR ls_fieldcat.

  ls_fieldcat-fieldname  = 'OVERDUE_DAYS'.

  ls_fieldcat-inttype    = 'N'.

  ls_fieldcat-reptext_ddic    = 'Overdue Days'(028).

  ls_fieldcat-intlen     = 5.

  ls_fieldcat-outputlen  = 5.

  ls_fieldcat-col_pos    = 29.

  APPEND ls_fieldcat TO lt_fieldcat.

  CLEAR ls_fieldcat.

  ls_fieldcat-fieldname  = 'PO_ITEM_QTY'.

  ls_fieldcat-reptext_ddic    = 'PO QTY'(029).

  ls_fieldcat-intlen     = 13.

  ls_fieldcat-outputlen  = 13.

  ls_fieldcat-col_pos    = 30.

  APPEND ls_fieldcat TO lt_fieldcat.

  CLEAR ls_fieldcat.

  ls_fieldcat-fieldname  = 'PO_GR_QTY'.

  ls_fieldcat-reptext_ddic    = 'GR QTY'(030).

  ls_fieldcat-intlen     = 13.

  ls_fieldcat-outputlen  = 13.

  ls_fieldcat-col_pos    = 31.

  APPEND ls_fieldcat TO lt_fieldcat.

  CLEAR ls_fieldcat.

  ls_fieldcat-fieldname  = 'PO_GR_DIFF'.

  ls_fieldcat-reptext_ddic    = 'PO/GR QTY DIFF'(031).

  ls_fieldcat-intlen     = 10.

  ls_fieldcat-outputlen  = 10.

  ls_fieldcat-col_pos    = 32.

  APPEND ls_fieldcat TO lt_fieldcat.

  CLEAR ls_fieldcat.

  ls_fieldcat-fieldname  = 'PAR_LBL'.

  ls_fieldcat-reptext_ddic    = 'LBL'(032).

  ls_fieldcat-intlen     = 11.

  ls_fieldcat-outputlen  = 11.

  ls_fieldcat-col_pos    = 33.

  APPEND ls_fieldcat TO lt_fieldcat.

  CLEAR ls_fieldcat.

  CALL FUNCTION 'REUSE_ALV_FIELDCATALOG_MERGE'

    EXPORTING

      i_program_name   = 'ZSAPTRX_EE_OVERDUE_LIST'

      i_structure_name = '/SAPTRX/EH_EXPEV'

    CHANGING

      ct_fieldcat      = fieldcat.

  LOOP AT fieldcat INTO wa_fieldcat1.

    READ TABLE l_cols INTO l_col

                       WITH KEY col_name = wa_fieldcat1-fieldname.

    IF sy-subrc = 0.

      wa_fieldcat1-col_pos = l_col-position.

      APPEND wa_fieldcat1 TO lt_fieldcat.

    ENDIF.

  ENDLOOP.

1. ENDFORM. "build_fieldcatalog

*&---------------------------------------------------------------------*

*&      Form  get_data

*&---------------------------------------------------------------------*

FORM get_data.

  DATA: l_tst       TYPE timestamp,

        save_guid   LIKE /saptrx/eh_info-eh_guid.

  DATA:  lt_exp_ev_guids TYPE TABLE OF to_ex_ev

          WITH HEADER LINE.

  DATA: li_hdr_info TYPE STANDARD TABLE OF zem_pur_eh

          WITH HEADER LINE.

  DATA: BEGIN OF t_params OCCURS 0,

          eh_guid LIKE /saptrx/eh_info-eh_guid,

          param_name  LIKE /saptrx/eh_info-param_name,

          param_value LIKE /saptrx/eh_info-param_value,

        END OF t_params.

  DATA: BEGIN OF li_params OCCURS 0,

          eh_guid         LIKE /saptrx/eh_info-eh_guid,

          po_number(10)   TYPE n,

          po_line(6)      TYPE n,

          matnr(10)       TYPE c,

          matx(33)        TYPE c,

          plant(4)        TYPE c,

          po_type(4)      TYPE c,

          po_org(4)       TYPE c,

          mrp_cntrl(3)    TYPE c,

          po_pln_dte      TYPE sy-datum,

          vendor_no(10)   TYPE c,

          vendor_name(20) TYPE c,

          po_item_qty(10) TYPE p decimals 0,

          po_gr_qty(10)   TYPE p decimals 0,

          par_label(11)   TYPE c,

      END OF li_params.

  CONSTANTS: co_not_expected TYPE /saptrx/ee_msg_status VALUE ' '.

  GET TIME STAMP FIELD l_tst.

  IF p_msgdat[] IS INITIAL.

    p_msgdat-sign = 'I'.

    p_msgdat-option = 'BT'.

    p_msgdat-low = '0'.

    p_msgdat-high = l_tst.

    APPEND p_msgdat.

  ENDIF.

  REFRESH meindex.

  LOOP AT p_msgdat.

    meindex-sign = p_msgdat-sign.

    meindex-option = p_msgdat-option.

    meindex-low = p_msgdat-low+1(12).

    meindex-high = p_msgdat-high+1(12).

    APPEND meindex.

  ENDLOOP.

  IF p_evtdat[] IS INITIAL.

    p_evtdat-sign = 'I'.

    p_evtdat-option = 'BT'.

    p_evtdat-low = '0'.

    p_evtdat-high = l_tst.

    APPEND p_evtdat.

  ENDIF.

  REFRESH eeindex.

  LOOP AT p_evtdat.

    eeindex-sign = p_evtdat-sign.

    eeindex-option = p_evtdat-option.

    eeindex-low = p_evtdat-low+1(12).

    eeindex-high = p_evtdat-high+1(12).

    APPEND eeindex.

  ENDLOOP.

  REFRESH evstat.

  evstat-sign = 'I'.

  evstat-option = 'EQ'.

  evstat-low = 'O'.

  APPEND evstat.

  REFRESH g_exp_ev.

  SELECT o~eh_guid o~ao_system o~ao_type o~ao_id o~trackingidtype

         o~trackingid e~event_code

         e~event_group e~partner_id_type e~msg_exp_date

         e~orig_msg_exp_dte e~earliest_msg_dte e~latest_msg_date

         e~msg_rcvd_date e~event_exp_date e~orig_ev_exp_date

         e~earliest_ev_date e~latest_ev_date e~event_date

         e~msg_status e~partner_id_type e~partner_id

     INTO CORRESPONDING FIELDS OF TABLE t_exp_ev

     FROM /saptrx/eh_hdr AS o INNER JOIN /saptrx/eh_expev AS e

     ON   o~eh_guid = e~eh_guid

     WHERE

     o~eh_active = c_true            AND

     o~trackingidtype    IN p_tridtp AND

     o~trackingid        IN p_trid   AND

     o~ao_system         IN p_ao_sys AND

     o~ao_type           IN p_ao_tp  AND

     o~ao_id             IN p_ao_id  AND

     o~bus_proc_type     IN p_trobtp AND

     o~eh_type           IN p_trtp   AND

     e~event_code        IN p_evcode AND

     e~event_group       IN p_evgrp  AND

     e~partner_id_type   IN p_parcs AND

     e~partner_id        IN p_parid  AND

   ( ( e~msg_status      IN evstat   AND

       e~msg_exp_index   IN meindex ) OR

     ( e~msg_status      = co_not_expected AND

       e~event_status    IN evstat AND

       e~event_exp_index IN eeindex ) ).

  APPEND LINES OF t_exp_ev TO g_exp_ev.

  SORT t_exp_ev BY eh_guid.

  lt_exp_ev_guids[] = t_exp_ev[] .

  DELETE ADJACENT DUPLICATES FROM lt_exp_ev_guids

    COMPARING eh_guid.

  SELECT eh_guid param_name param_value INTO TABLE t_params

      FROM /saptrx/eh_info FOR ALL ENTRIES IN lt_exp_ev_guids

      WHERE  eh_guid = lt_exp_ev_guids-eh_guid.

  SELECT eh_guid param_name param_value APPENDING TABLE t_params

      FROM /saptrx/eh_cntrl FOR ALL ENTRIES IN lt_exp_ev_guids

      WHERE  eh_guid = lt_exp_ev_guids-eh_guid.

  SELECT * INTO TABLE li_hdr_info FROM zem_pur_eh

   FOR ALL ENTRIES IN lt_exp_ev_guids

      WHERE  eh_guid = lt_exp_ev_guids-eh_guid.

  SORT: t_params BY eh_guid, li_hdr_info BY eh_guid.

  CLEAR save_guid.

  LOOP AT t_params.

*combine all parameter values for the same guid

    IF NOT save_guid IS INITIAL.

      IF NOT t_params-eh_guid = save_guid.

        save_guid = t_params-eh_guid.

        APPEND li_params.

        CLEAR li_params.

        li_params-eh_guid = t_params-eh_guid.

      ENDIF.

    ELSE.

      li_params-eh_guid = t_params-eh_guid.

      save_guid = t_params-eh_guid.

    ENDIF.

    READ TABLE li_hdr_info

     WITH KEY eh_guid = t_params-eh_guid

     BINARY SEARCH.

    IF sy-subrc = 0.

      li_params-po_number = li_hdr_info-po_number.

      li_params-plant     = li_hdr_info-plant.

      li_params-po_type   = li_hdr_info-po_type.

      li_params-vendor_no =  li_hdr_info-vendor_no.

    ENDIF.

    IF t_params-param_name = 'PO_NUMBER'.

      li_params-po_number = t_params-param_value.

    ENDIF.

    IF t_params-param_name = 'VENDOR_NUMBER'.

      li_params-vendor_no = t_params-param_value.

    ENDIF.

    IF t_params-param_name = 'VENDOR_NAME'.

      li_params-vendor_name = t_params-param_value.

    ENDIF.

    IF t_params-param_name = 'PO_LINE_NUMBER'.

      li_params-po_line = t_params-param_value.

    ENDIF.

    IF t_params-param_name = 'MATERIAL'.

      li_params-matnr = t_params-param_value+8(10).

    ENDIF.

    IF t_params-param_name = 'MATERIAL_TEXT'.

      li_params-matx = t_params-param_value.

    ENDIF.

    IF t_params-param_name = 'PURCHASE_ORG'.

      li_params-po_org = t_params-param_value.

    ENDIF.

    IF t_params-param_name = 'MRP_CONTROLLER'.

      li_params-mrp_cntrl = t_params-param_value.

    ENDIF.

    IF t_params-param_name = 'PO_LATEST_DLV_DATE'.

      li_params-po_pln_dte = t_params-param_value.

    ENDIF.

    IF t_params-param_name = 'PO_ITEM_QTY'.

      li_params-po_ITEM_qty = t_params-param_value.

    ENDIF.

    IF t_params-param_name = 'PO_GR_QTY'.

      li_params-PO_gr_qty = t_params-param_value.

    ENDIF.

    IF t_params-param_name = 'PARTICIPATION_LABEL'.

      li_params-par_label = t_params-param_value.

    ENDIF.

  ENDLOOP.

*in case of 1st or last

  IF NOT li_params IS INITIAL.

    APPEND li_params.

  ENDIF.

  DELETE li_params WHERE

po_number NOT IN s_ponum  OR

matnr     NOT IN s_matnr  OR

plant     NOT IN s_plant  OR

po_type   NOT IN s_potyp OR

po_org    NOT IN s_poorg   OR

                    mrp_cntrl NOT IN s_mrpcrl  OR

po_pln_dte  NOT IN s_plndte OR

vendor_no NOT IN s_vndno    or

par_label not in s_lbl.

  LOOP AT g_exp_ev ASSIGNING <fs_exp_ev>.

    READ TABLE li_params WITH KEY

       eh_guid =  <fs_exp_ev>-eh_guid

       BINARY SEARCH.

    IF NOT sy-subrc = 0.

      DELETE g_exp_ev." from <fs_exp_ev>.

    ELSE.

      <fs_exp_ev>-po_number = li_params-po_number.

      <fs_exp_ev>-po_line   = li_params-po_line.

      <fs_exp_ev>-matnr     = li_params-matnr.

      <fs_exp_ev>-matx      = li_params-matx.

      <fs_exp_ev>-plant     = li_params-plant.

      <fs_exp_ev>-po_type   = li_params-po_type.

      <fs_exp_ev>-po_org    = li_params-po_org.

       <fs_exp_ev>-mrp_cntrl = li_params-mrp_cntrl.

      <fs_exp_ev>-po_pln_dte  = li_params-po_pln_dte.

       <fs_exp_ev>-vendor_no = li_params-vendor_no.

      <fs_exp_ev>-vendor_name = li_params-vendor_name.

      <fs_exp_ev>-po_item_qty = li_params-po_item_qty.

       <fs_exp_ev>-po_gr_qty  = li_params-po_gr_qty.

      <FS_EXP_EV>-PAR_LBL  = li_params-par_label.

*get number of overdue days

      IF NOT <fs_exp_ev>-event_exp_date IS INITIAL.

        date1 = <fs_exp_ev>-event_exp_date+1(8).

        date2 = sy-datum.

        time1 = <fs_exp_ev>-event_exp_date+9(6).

        time2 = sy-uzeit.

        PERFORM datetime_difference

                USING date1 time1 date2 time2

                  datediff .

        IF sy-subrc = 0.

           <fs_exp_ev>-overdue_days = datediff.

        ENDIF.

      ENDIF.

*get po/gr qty diff

      <fs_exp_ev>-po_gr_diff =

      <fs_exp_ev>-po_item_qty - <fs_exp_ev>-po_gr_qty .

    ENDIF.

  ENDLOOP.

ENDFORM. " get_data

*&---------------------------------------------------------------------*

*&      Form  F4_FOR_VARIANT

*&---------------------------------------------------------------------*

FORM f4_for_variant .

  CALL FUNCTION 'REUSE_ALV_VARIANT_F4'

       EXPORTING

            is_variant          = variante

            i_save              = variant_save

       IMPORTING

            e_exit              = variant_exit

            es_variant          = def_variante

       EXCEPTIONS

            not_found = 2.

  IF sy-subrc = 2.

    MESSAGE ID sy-msgid TYPE 'S' NUMBER sy-msgno

            WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.

  ELSE.

    IF variant_exit = space.

      p_vari = def_variante-variant.

    ENDIF.

  ENDIF.

ENDFORM. " F4_FOR_VARIANT

*&---------------------------------------------------------------------*

*&      Form  PF_STATUS_SET

*&---------------------------------------------------------------------*

FORM status USING     extab TYPE slis_t_extab.

  SET PF-STATUS 'STANDARD_FULLSCREEN'.   "EXCLUDING EXTAB.

ENDFORM. "STATUS

*&---------------------------------------------------------------------*

*&      Form  USER_COMMAND

*&---------------------------------------------------------------------*

FORM user_command USING r_ucomm LIKE sy-ucomm

               rs_selfield TYPE slis_selfield.

  DATA: ls_ee    TYPE to_ex_ev,

        l_tabix LIKE sy-tabix.

  l_tabix = rs_selfield-tabindex.

  CASE r_ucomm.

    WHEN 'DETAILS' OR '&IC1'.

      READ TABLE  g_exp_ev INTO ls_ee INDEX l_tabix.

      CALL FUNCTION '/SAPTRX/EH_DETAILS'

        EXPORTING

          i_guid = ls_ee-eh_guid.

  ENDCASE.

ENDFORM.                               " USER_COMMAND

*&---------------------------------------------------------------------*

*&      Form  DATETIME_DIFFERENCE

*&---------------------------------------------------------------------*

*       Calculate difference between two dates/times                   *

*----------------------------------------------------------------------*

*  -->  date1 Date 1

*  -->  time1 Time 1

*  -->  date2 Date 2

*  -->  time2 Time 2

*  <--  daydiff Datedifference (absolute)

*  <--  hourdiff Timedifference (absolute)

*  <--  earliest Flag to show which datetime is earlier (1 or 2)

*----------------------------------------------------------------------*

FORM datetime_difference

       USING date1 TYPE d time1 TYPE t

             date2 TYPE d time2 TYPE t

             daydiff TYPE p .

  DATA: d1 TYPE d, d2 TYPE d, t1 TYPE t, t2 TYPE t.

  DATA: timediff TYPE t,

        hourdiff TYPE p,

        earliest TYPE c.

  FIELD-SYMBOLS: <h>, <m>, <s>.

* Which date/time is earlier ?

  IF date1 > date2.

    earliest = '2'.

  ELSEIF date2 > date1.

    earliest = '1'.

  ELSE.

    IF time1 > time2.

      earliest = '2'.

    ELSEIF time2 > time1.

      earliest = '1'.

    ELSE.

*---- Both are equal

      earliest = '0'.

      daydiff = 0.

      hourdiff = 0.

      EXIT.

    ENDIF.

  ENDIF.

* Assign dates / times and swap it if necessary

  IF earliest = '1'.

    d1 = date1.

    t1 = time1.

    d2 = date2.

    t2 = time2.

  ELSE.

    d1 = date2.

    t1 = time2.

    d2 = date1.

    t2 = time1.

  ENDIF.

* Calculate hours difference

  timediff = t2 - t1.

  ASSIGN timediff+0(2) TO <h>.

  ASSIGN timediff+2(2) TO <m>.

  ASSIGN timediff+4(2) TO <s>.

  hourdiff = <h> + ( <m> / 60 ) + ( <s> / 3600 ).

* If no date difference then exit

  IF d2 = d1.

    daydiff = 0.

    EXIT.

  ENDIF.

* Check for time underflow and correct second date

  IF timediff > t2.

    d2 = d2 - 1.

  ENDIF.

* Calculate date difference

  daydiff = d2 - d1.

ENDFORM.                               " DATETIME_DIFFERENCE

In my previous blog I spoke about the benefits as they pertained to the Order to Cash process. Now it's time to dive in to a little detail on how to configure certain functionality. 1st up is the integration with SAP Business Workflow...

First a couple of notes before we get started:

• SAP Business Workflow is tightly integrated with SAP Event Management
• Several scenarios come with pre-delivered content for creating workflows
• Can deliver workflows to uers in several ways:
  • SAP Business Workplace
  • Universal Work List (UWL) / Portal

How does the process look?

SAP EM detects exception --> Launch workflow – Take action – “Do work” (OR Send alert - Notification) --> Update status – For reporting

What do we get out of it?

• Visibility in SAP EM: Status available to all   <-- People see an issue is in play
• Workflow: Real time notification with the right information to the right person with no wait time between issue detection and launching corrective action <-- An agent is correcting the issue

E.g. Purchase Order Acknowledgement  with Qty discrepancy: Create PO --> Create PO Acknowledgement for qty < PO --> SAP EM detects the discrepancy and launches corrective action with workflow

Development Steps - SAP ECC

The development steps needed are as follows:

• STEP 1 - Create the Business Object Event in ECC (transaction SWO1)
  • BUS2012 (Purchase Order)
    • Event: ACK

• STEP 2 - Create the workflow (transaction PFTC)
  • The BO event ‘ACK’ will trigger the workflow

Configuration Steps - SAP ECC

• STEP 1– Activate the SAP EM / workflow event linkage (transaction SWETYPV)
  • Generates the BO event that will ultimately launch the workflow

• STEP 2– Activate the BO event linkage (transaction SWETYPV)
  • Example shown below: Object BUS2012 event ACK launches the workflow WS90000001

Configuration Steps – SAP EM

• STEP 1– Create the Workflow Activity ID
  • Link BUS2012 (Purchase Order) and  BO Event: ACK
  • Link PO number as the Business Object Key
  • Create and Link the Ack qty as a parameter

• STEP 2– Update the Rule Set
  • Call activity WORKFLOW_START (connected to Activity ID created in STEP 1)

Seeing it in action

• Task list below shows WORKFLOW_START activity was successfully started

• SWEL shows the event trace with 2 entries. The 1st shows START_WORKFLOW event triggered which starts the 2nd event BUS2012 --> ACK which triggered workflow WS90000001 which appears in the agents workflow inbox (transaction SBWP)
  • Clicking the object in the workflow takes you to ME23N to view the PO

Simple to do and Very, Very powerful, ...

Daniel Haerder wrote a good blog introducing customizing of the SAP EM Web UI. Check it out here before continuing ... Now let's explore it in more detail.

Reference the following 2 links to give you more ideas around what is possible:

• http://help.sap.de/saphelp_nw73/helpdata/en/73/142b2a79fb4884a4b4e87fa88f4115/frameset.htm
• http://help.sap.de/saphelp_smehp1/helpdata/en/7b/fb57412df8091de10000000a155106/content.htm

Setting the theme back to SAP standard

Add parameter &sap-theme=sap_standard to the end of your URL. E.g. http://sapei01.qdatausa.com:8000/sap/bc/webdynpro/saptrx/em_fpm_ui?sap-system-login-basic_auth=X&sap-client=100&sap-language=EN&sap-theme=sap_standard#

Available themes:

• sap_chrome
• sap_hcb
• sap_highcont
• sap_nova
• sap_standard
• sap_tradeshow
• sap_tradeshow_plus

Configuring the Web UI

Add the parameter "&sap-config-mode=X" at the end of the SAP EM Web UI. E.g. http://<WEBUI>/sap/bc/webdynpro/saptrx/em_fpm_ui?sap-client=100&sap-language=EN&sap-config-mode=X

Right click on a field and select “Settings for current configuration”

Right click element and select “Add decorative item”

Can add one of the following:

• Heading
• Explanation
• Formatted Text
• Horizontal Separator
• Image
• Link
• Text Display

Adding a logo to your SAP EM Web UI

Right click on a field and select “Settings for current configuration”

Right click PAGE_HEADER_TITLE_CONTENT and select “Add decorative item”

Select image

Add Image Source, Tooltip and Location URL to send to as shown below

And you end up with...

Changing the Text on the Selection Screen

Cross-Application Settings for Web Dynpro ABAP

Use Web Dynpro WD_GLOBAL_SETTING to set global web Dynpro settings for all applications.

http://sapei01.qdatausa.com:8000/sap/bc/webdynpro/sap/WD_GLOBAL_SETTING#

General Parameters

Adjustments Design and Side-Panel

An IoT Proof of Concept – Using HCP IoT Services and on premise SAP Transportation Management/Event management for Cold chain monitoring

Here is a PoC which uses an IoT device (Ti Sensor Tag CC2650), HANA Cloud Platform IoT Services, HANA Cloud Connector (HCC) and on premise SAP application systems(TM and EM). The PoC is built to monitor the temperature of a Freight Order (FO) which transports temperature sensitive products like medicines or meat or vegetables. For those who are not familiar with SAP TM or SAP EM: - please refer relevant SCN pages, TM and EM.

Scenario Scope:

• Freight order is created in SAP TM which  holds products with restricted temperature requirements
• Event Handler created in SAP EM with control parameters for temperature requirements
• A sensor (attached to the truck which carries the FO) is used to capture surrounding temperature and send this (via smart phone over cellular network) info to HCP IoT services.
• JAVA persistence API and Hana Cloud Connector used to send this info to on premise SAP EM system as event message
• EM ruleset determine the temperature limits and inform the concerned persons via e-mail

Required Software Components

• An account in HCP trial via registering athttps://hanatrial.ondemand.com
• A sensor device to capture temperature, I used tiSensorTag
• An iPhone with an app called IoTSensor
• HANA Cloud connector installed on your local machine (or on premise box). Follow this blogfor installation procedure (up to step 4 would be sufficient). This helps to connect applications deployed on HCP to existing on premise system. HCC need not necessarily installed within on premise firewall.

Now we start with configuring HCP for our requirements. You must create a trial user in HANA cloud trial version before proceeding with next steps described here.

1. We will start with configuring IoT Services Cockpit.

1.1  After logging into your trial version, navigate to Services menu on the left side panel. Search for service called ‘Internet of Things Services’ and enable the service. As a result, the subscriptions for the Internet of Things Services cockpit and RDMS will be automatically created for the account as described in this SAP Help portal:Internet of Things Services Cockpit.

1.2  Now you have to deploy Message Management Service(MMS) by following this sap help doc

1.3  To access the Message Management Service (MMS) cockpit and to use the sample clients that are available for the Data Services as well as for the Push Service, a user must have been assigned the role IoT-MMS-User. You can refer here to assign this role.

1.4  Next step is to create Device type and Message Type in IoT Service Cockpit. Navigate to ‘Internet of Things Services’ under Services section on the left side panel of the HCP Cockpit. Click on ‘Go to Service’ which open IoT Service Cockpit in another window.

1.5  Click on device Types tile

1.6  Create a new Device Type by clicking ( + ).

1.7  Enter a name like ‘hpiPhone’ or something like that.

1.8  Go back to the Internet of Things services Cockpit.

1.9  Choose the Message Types tile.

1.10 Create a new Message Type by clicking ( + ).

1.11

Enter a name, e.g. "tiSensorTag". Select the device Type as previously created and direction as ‘From Device’. You may choose the following as Fields.

After hit ‘Save’ it will generate an ID for this message Type.

1.12 Note the Message Type ID, Device ID and Device Registration Token.

1.13 Install IoTSensor app on your iPhone.

1.14 For registering the device on HCP, easiest way is to prepare the below url in an outlook e-mail

iot-create://&/accountName&/[Account ID]&/name&/[Connection Name]&/dataCenter&/[Data Center]&/deviceName&/[Device Name]&/deviceTypeID&/[Device Type ID]&/deviceReg&/[Device Registration Token]&/messageTypeID&/[Message Type ID]

Parameters:

[Account ID] => your account ID, e.g., "p1234567trail"

[Data Center] => your account data center, e.g., "hanatrial”

[Connection Name] => any name for a connection, e.g., "myConnection"

[Device Name] => any name for the device, e.g., "iPhone HP" / "Sensor Tag 1"

[Device Type ID] => the Device Type ID you noted at step 1.12

[Device Registration Token] => the Device Registration Token you noted at step 1.12.

[Message Type ID] => the Message Type ID you noted at step 1.12.

Send this URL to your e-mail which you can open from your iPhone. A sample url would look like this:

iot-create://&/accountName&/p1234567trial&/name&/mytiTagiPhone&/dataCenter&/hanatrial&/deviceName&/iPhoneHari&/deviceTypeID&/9e21d36c88408c52ccf1&/deviceReg&/9053658c88ef2b2cff84b2aff5f7719&/messageTypeID&/eb5f056d0a86232bb493

1.15 Open your e-mail and click on this URL. This will automatically launch the IoTSensor app you installed at step 1.13.

1.16 Press on Registration. The device gets registered successfully.

1.17 You can see the registered device in the IoT Service Cockpit as shown below. Click on ‘Devices’ tile

Now you are done with IoT Cockpit settings and you can start testing its configurations by sending some sample sensor signals. For this

1.18 Open the IoTSensor App on your iPhone

1.19 You can see the "Connection" is now colored red. Press on ‘Sensor’.

1.20 Make sure Bluetooth is ON in your iPhone and TI SensorTag is ON (just press the ON button on the SensorTag device).

1.21 Select a device by selecting the connected SensorTag. Press ‘Refresh’ icon if SensorTag is not yet listed.

1.22 Go back to the previous screen and then again click Go Back. Now you will see both Sensor and Connection colored red.

1.23 Now press the record button. Data will send according to the sending interval.

1.24 You can see the sensor data in MMS cockpit. Choose the Send and view messages, or perform other actions tile (The MMS Cockpit opens.) from the Internet of Things Services Cockpit. Choose the Display stored messages tile. (All tables of incoming data are listed.). Select the table that is named after the Message Type ID that you created previously ("T_IOT_<MESSAGE TYPE ID>").

2. Our next logical step is to configure HCP connection with on premise system using HANA Cloud Connector.

2.1  You might have completed the HCC installation as described in this blog during Required Software Component section above. You will see the connection state as shown below if you completed the steps successfully.

2.2  Next step is to create an access control to on premise SAP Event Management system by ‘Add’ System Mapping and providing the below details. Maintain your own system host name. You could test the connection by click on ‘Check’ button.

2.3  Now we have to give access to a resource (here in this case an RFC FM in SAP Event Management System) in the above system. You may create a wrapper function module for standard SAP BAPI FM ‘/SAPTRX/BAPI_EH_ADDEVENTMSG_02’. This RFC FM is used to post events in EM. Here in this case we have to pass the sensor temperature as event data. So create a remote function module in Z namespace which accept the temperature and sensor ID and timestamp, latitude and longitude. Code snippet below.

Once you activate the FM, switch back to HCC Administration page. Select the System mapping you created in step 2.2, and under the ‘Resource Accessible On …’ table below, click ‘Add’ and provide the below details. With this we are done with HCC set up.

2.4  You can see in HCP cockpit, under Connectivity section, you have an HCC connection up and running by now.

2.5  Now navigate to ‘Destinations’ in HCP cockpit and add a New Destination to your SAP on premise EM system.

Add the system with your own details as seen in the above screenshot. Jco.client.mshost is the message server of your backend SAP system if you are using load balancing, else use jco.client.ashost property to set application server.

3. JPA for message Reading from MMS and send to on premise system via HCC

So far, we have configured IoT Services Cockpit to receive messages from sensor device and HCC setup for passing the message to on premise SAP Event Management system. But this is not enough- we need to read the sensor message from IoT MMS data source table and call the resource (the EM BAPI) we configured via HCC. There are multiple ways to do this as described in this SAP Help portal. I use Java Persistence API(JPA)  for this purpose. We have to deploy a small Java Servlet application on HCP which does this trick. Attached the sample code for this servlet.

3.1 Import the project into eclipse as dynamic web project and then make necessary changes to the SensorServlet.java file with your own destination name(as per section 2.5), function module name(as per section 2.3) and MMS table name(as per section 1.24). Deploy the project into HCP, you may refer this blog step 4.6 if you don’t know how to deploy into HCP.

After deployment, you will see the application under Java Applications section in HCP Cockpit.

3.2       Since in the servlet we want to read the data in the MMS, we have to change the default data source binding to MMS data source. For this click on the deployed project name (localproject here)  and then click ‘Data Source Binding’ on the left side panel. Delete the default binding which already there by clicking ‘Delete’. Then select ‘New Binding and change the Schema ID to xxxxtrial.iotmms.web.

Make sure you have the below settings under ‘Destinations’.

3.3 The servlet we have deployed can read and send the sensor data stored under MMS. But when we should send this data to on premise will be a question. We can think of the something which trigger this ‘read and send’ – that is pushing the message to on premise system OR pulling the message from on premise system. I followed pushing the message to on premise system approach for this PoC. There is a concept of Message Processing for MMS in HCP IoT Services. By default MMS uses processing service as ‘SQL’ which means all messages are stored in a database. We can use another processing service called Message Forwarding (HTTP)– this can be used to forward an incoming message or notification of the message to web services. I have configured this to notify my servlet whenever a message comes for a specified device type and message type. This way whenever a message comes from my sensor device, my servlet is executed which read the message from MMS data source and send to on premise EM system. This can be done little more easily by just forward the message to an EM web service, but I have not tried this way. The reason is you may lose the message in case some web service failure or something as message forwarding won’t store the message in MMS, but notification will do.

The HTTP Processing Service can be configured by submitting an HTTP PUT request to:

https://<host>/com.sap.iotservices.mms/v1/api/http/processing.

I used a chrome browser tool called postman REST client for this purpose. Just select PUT as a service and send the below text.

{

"deviceType": "9e21d36c88209c52cf53",

"messageType": "eb5f056d0a86232kk481",

"processingServices": [

    {

      "name": "sql",

      "add_default_columns": true,

       "mms.processing.sql.schema_name": "p1234567trial.iotmms.web",

"mms.processing.sql.hana.table_type": "column"

      },

      {

      "name": "http",

      "properties": {

        "mms.processing.http.url": "https://iotservletp1234567trial.hanatrial.ondemand.com/localproject/?action=connect",

"mms.processing.http.send_mode": "notification",

"mms.processing.http.auth_mode": "basicauth",

        "mms.processing.http.basicauth.username": "yourHCPusername",

        "mms.processing.http.basicauth.password": "YourHCPPassword"

      }

    }

]

}

Change the device type, message type, schema name, http.url, username and password which matches with your settings. In the http.url, ‘?action=’ can be any action name, we are just checking in the servlet code whether the action is null or not. You will get the URL of the servlet project from HCP cockpitàJava Applications. Click on the servlet project link and there you can see the URL under Application URLs.

*************************************************

By now, we have all configurations in HCP Cockpit, HCP IoT Service Cockpit, HCP IoT MMS Service and HCC. I have not gone in details with other application settings in EM or TM. I will publish another blog with this settings later. But if you have some idea on EM and TM, this would be easy as we have the message ready to be pushed to EM. We should have a ruleset in EM which check the temperature and compare the threshold control parameters and trigger and alert e-mail if it is out of range. The sensor device ID registered in HCP shall be the tracking ID of the freight order. Standard configuration in EM will push this event message to TM where we can further process this and model some business scenario like re planning FO/event based charging etc.

Your views and improvement recommendations welcome