process observer in-depth workshop

Process Observer is a component in the SAP Business Suite Foundation layer that can be used to monitor the built-in processes of SAP Business Suite, like Order-to-Cash or Procure-to-Pay, Payment etc. .

1

Note: Process Observer is available from- Business Suite Foundation 731 - Business Suite Foundation 702 SP06- Business Suite Foundation 701 SP11

The scope of this training covers Process Observer in these releases or higher:- Business Suite Foundation 731 SP02- Business Suite Foundation 702 SP08- Business Suite Foundation 701 SP11

There may be some deviations and limited functionality in lower SP levels.

Managing business change and business automation are important requirements in today‘s world.Our customers want to manage and monitor business processes along the lifecycle, and seamless across Business Networks and across SAP and non-SAP applications.

Process as purpose (value)Process as chain/flowProcess is the linchpin

6

The value proposition of Process Observer is to:

Gain full Process Visibility, enablingReal-time Monitoring including exception & error handlingBusiness Activity Monitoring & SLA TrackingTransparency on process quality

Process Optimization allow to differentiate by strengthening operations through continuous process improvements

Insight-to-action take action as soon as issues show up on the horizon

Enhanced Process Automation

7

In the Business Suite we find 2 kinds of processes:

Modeled Process for process extensions and built-in for SAP standard delivered processes, the “applications” (Suite)

Modeled Process Process engine executes processes according to process definitions

Built-in ProcessBusiness logic executed without use of an explicit process engineCollaboration treated as built-in process since activities of different actors are driving

Built-in processes make up 95% of delivered Business Suite funtionality.

Typical implemented End-to-end process is a mixture of both orchestration types

9

Sample of an End-to-End process, spanning two local Built-in processes.

10

Message Error Handling: IDOC error handling and FEH integrated – planned

12

High-Level Concept of Process Observer

Execution of Business Process Activities exposed via events‘Process Observer’correlates events into local processes and determines KPIsLocal storage of local processes and their KPIsFederated process log End-to-end Process Visibility, Monitoring and Analytics

13

Design time:The Process Repository contains informations about know Events and Business Objects of the application (the „Facade“), and „process definitions“. Process definitions are simple bills of activities that may occur in the process. KPIs may be assigned to the process definitions. Process definitions are required to monitor processes in Process Observer.

Runtime:- A user executes an activity in the system. This could also be something calleed from another program, e.g. A service.- The application raises a BOR-event. This is captured by Process Observer, and mappe dagains a process model. One or many activities are determined- The activity is mapped to a process instance and stored in the process log.- The process log data is available for monitoring through APIs.- Process log data is also avialable for analytics.

14

Process KPIs are calculated locally during Runtime by Process Observer. Aggregated KPIs like averages are calculated by BW, ODPs or HANA. Thresholds are used to trigger actions.

IndicatorIs a measurable quantity

EvaluationIs associated with and assesses indicator valuesIts scope will be defined depending on the business perspective – Targets, classifications, ranges, benchmarks, thresholds

ActionViolation of objectives defined in assessments requires specific actions to be taken

Action Plan

Conclusion: Process Analytics require Analytical Environments like SAP BI

Bundles indicators, assessments, actions, perspectives

15

Business Process Intelligence (BPI) is the framework on top of BPM which describes and supplies

the principlesarchitectures infrastructures

for the support of these insightsBAM like techniques and Analytics techniques are coming together

BPI ingredientsBusiness Process Management and Business Applications

Models of business processes Execution of business processes and (composite) business applications Event consumption and provisioningBusiness Process IntelligenceProcess Monitoring, Process Visibility, Process Analytics, KPI, SLABusiness Activity MonitoringProcess AnalyticsBusiness Intelligence InfrastructureDashboards and Monitoring CapabilitiesComplex Event ProcessingEvent Models and MetadataEvent Resolution Event Processing / Provisioning / ConsumptionDistributed & Federated Processing

Business KPIs (e.g. revenue) based on transactional data (e.g. order data) Process data based on process logs (e.g. event „order created“)Process KPIs (e.g. order lead time) Get insight within the context of E2E process and take action (e.g. orders with high volume and overdue delivery)

16

This diagram shows how Process Observer is integrated into other tools:

The Process Log is the central component to give insight to you processes and to trigger follow up actions.Events about process execution are thrown by SAP or non-SAP applications and stored in the process log. Process log information can be queried via Enterprise Search, or by accessing the Process Monitor directly. From here you can navigate to process-related business objects.Light-weight consumption is possible via ODATA/Gateway.Datasources allow the extration to and direct access from Business Warehouse. Real-time data access (RDA) is available. Analytics Data is also available through ODPs. The existing datasources can be used to replicate process log information to HANA via ETL. Alternatively the process log tables can be replicated directly using SLT. The report-report interface allows navigation between reports, and to backend applications.Additionally, process log content be made available for applications through sidepanels.

17

Use case Perfect Order Delivery:

Perfect Order Rate: The Perfect Order Rate calculates the error-free rate of each stage of a Sales Order. This measure should capture every step in the life of an order. For almost all issues that occur along the sales order life cycle , a corrective ‘weight’ is issued. It is through an aggregated analysis of these ‘weights (credits)’ that the metrics is derived.

Example:Order Entry Accuracy: 99.95% Correct (5 errors per 10,000 order lines)Warehouse Pick Accuracy: 99.2%Delivered on Time – based on cycle times (actual versus promised): 96% Invoiced Correctly: 99.8%

Perfect Order Rate is 99.95% * 99.2% * 96% * 99% = 94.23%

19

Ingredients for Delivery-on-Time:

Sales Order Item Promised Cycle Time: The anticipated or agreed upon cycle time of a Sales Order Item. It is the gap between the Sales Order Creation Date and the Requested Delivery Date. (Confirmed date (GI date) – PO date (in SO))Sales Order Actual Item Cycle Time: The average time it takes to actually fulfill a sales order item. This measure can be viewed on an order or an order item level. The measure starts when the customers order is sent/received/entered. It is measured along its various steps of the order cycle. The measure ends at either the time of shipment or at the time of delivery to the customer. (Actual GI date – SO creation date)Comparison and Variance Analysis: Sales Order Promised vs. Actual Cycle Time: variance absolute and % based on ‘Promised cycle time’ Drill down and analytical analysis based on customer master data attributes, organizational data (sales organization, sales rep etc.)

cycle time per customer (aggregation per customer as arithmetic average)

20

Lab-preview dashboard Delivery-onTime: Process Observer calculates actual duration for goods issue and compares with promosed duration. Process Observer data is be combined with Sales Order Data in a BI environment to get business insights.

21

MDG supports create and change requests for master data like material or business partner. The initial change is done on the SAP MDG-Hub server triggerend by a MDG change request workflow. The master data is then distributed to client systems, where additional workflows can be triggerend and further, client specific data can be maintained.Process Observer can be used to monitor the workflow cross MDG-hub and clients.

MDG instrumentation for Process Observer will be provided with RDS „MDG Content Accelerator“ (currently in development).

22

Process Object Builder 1.0 is planned for ramp-up in August 2012. Process Objects from Process Object Layer (POL) are instrumented to use Process Observer for monitoring. The target is to monitor the entire orchestrated process using Process Observer.

23

Note: Activating the Business Function is essential.IMG nodes for Process Observer will only appear after the activation of the Business Function.No logging of events will happen, if the Business Function is not activated.The Business Function is reversible.

Using transaction POC_MODEL_CHECK you can check, whether the business function is activated. Run it with flag “Additional checks” selected. (This is SP level dependent and not available with 702SP06/07.)

28

No logging of events will happen, if process logging is not activated.Process Logging can be at any time deactivated and reactivated.

Raised and registered BOR events are filled into buffer table SWFREVTPOQ before being processed by Process Observer.Non-BOR events [(External) Event API] are filled into buffer tables POC_D_EVTQ and POC_D_EVTQ_PREBO before being processed by Process Observer.

29

Alternative Transaction POC_JOB_SCHEDULER to start the batch job.The batch job is client dependent.

Job ‘POC_JOB_XXX’ runs report POCR_MAIN_QUEUE, which in a sequence starts the following reports:

- RSWFEVTPOQUEUE: cleans BOR event buffer table and hands over to Process Observer in packages of 1000 events

- POCR_PROCESS_EVENTQUEUE : cleans non-BOR event buffer table and hands over to Process Observer in packages of 1000 events- POCR_TRACK_THRESHOLD: checks exceedance threshold Only one instance of the reports is allowed to run a the same time (singleton check).

For advanced setup the reports can also be scheduled independently in SM36.

The scheduled reports can be found in SM37 with status ‚Released‘.

Note: when Process Observer is activated you should definitely also schedule the jobs for event processing to make sure that there will be no overflow in the buffer tables.

30

Alternative: Transaction POC_MODEL_CHECK will indicate if the business function is activated, if Process Observer Logging was activated and if the job is scheduled if “Additional checks” is activated.

31

• Unless you find this log in the process monitor, Process Observer is not activated correctly.

32

Transactions – as in POC_MONITOR, SE38 - in POB are “Callable Business Entities”; they provide the information on mode a execution of these activities. E.g. Transaction, Workflow, SOA service, etc.

If you need to monitor existing BOR events, switch ON the BOR trace for all your activities by using the transaction ‘SWEL’ and monitor all BOR events that occur in the system. Some BOR events require additional configuration to be raised, either because the application does not raise them always, then some application specific customizing is required. Or because some generic framework that is active needs to be configured to raise BOR events, e.g. the change documents (see transaction SWEC) or the post processing framework (PPT).

37

Implementation LayerThe implementation layer represents the built-in processes. For the current Business Suite this is the existing ABAP implementation in ERP, SRM, CRM etc. The main object of the implementation layer is the callable entity. This is an abstraction of components existing in the current software that encapsulate some business relevant functionality which is executed independently within a logical unit of work (LUW, see below) thus it guarantees transactional integrity when data is changed. A callable entity provides or invokes specific business functionality. For the current Business Suite classes of callable entities are UI Transactions, different types of services, like enterprise services and RFCs, but also batch processes and even mobile transactions. The status of analytic UIs has to be considered; other, possibly application-specific incarnations of callable entities may exist. Each BO activity is linked to a (primitive) event that is raised by the business logic. It is here that the existing business events link into the process meta-model. The task event logging, as the relevant activity to gather information of the process being executed, is based on the activity events.For the Business Suite BO activity as well as business object, business object node and actions are conceptual entities. They can be used on a semantic level to organize existing functionality and split it into smaller parts. There are no instances of these objects found as specific development objects. (Primitive) events are existing development objects, but in the current Business Suite there is no model that links them to BO activities or callable entities, but this will be very much required to help create process models.

Application Façade LayerThe application façade encapsulates the entities of the implementation layer to put them at the disposal of the process layer. The entities of this layer are created to support the requirements of the process layer. Only the entities of the implementation layer that are process relevant are considered here.The callable business entity is the projection of the callable entity in the façade layer. It is the basic building block that is visible to the process layer and that is used to effectively model the built-in processes. For workflow it is necessary that this entity or an equivalent is available to build workflows, i.e. a software interface is ready for use that allows the execution of the callable entity by an external engine rather than by the built-in process or human interaction. A callable business entity can be used by many different processes definitions.The (reusable) task represents the BO activity of the implementation layer in the façade. It is channel-independent and the smallest self-contained operation with business process relevance on one business object and has defined business semantics.The task has a related task event that is used to relate the (primitive) event through the activity binding to the activity at runtime. The task is also helpful to document the semantics of the callable business entity. The BO activity a task links to is an actual development object. Generally every object of the facade has a corresponding object in the implementation.Currently the entities of the façade layer do not exist in the system. The entities and the necessary infrastructure are needed within or close to the development environment.

Process Model LayerThe process model layer contains the existing process models of the built-in processes. The primary entity – effectively the core object of BPM – is located here: the (compound realized) process. In order to show the key elements of the process definition below, versions are not included here as dimensions of the process definition. For each process definition several versions can be exist in parallel. One of those versions is defined to be the “currently active” one. All new process instances of this type of a built-in process will refer to this version until a new “currently active” is defined. Already running processes will be executed based on the version of the process definition that was the current active one when the process has started. This is the same concept which is state of the art for processes executed as workflows. For the following description of the meta-model the version is not relevant since every entity is part of a version.A process consists of a list of sequential and parallel activities. The activities serve to separate the overall process into pieces. Each activity must be self-contained and serve a well defined business purpose. It is typically executed as one action by a single user. One or many callable business entities are assigned to an activity. Thus the activity becomes channel-independent, when looking at UI and enterprise service as different channels. Example: An activity “Create sales order” may be executed by a user using the UI-channel transaction VA01 or triggered through the B2B-message channel.The process can be thought of as graph consisting of nodes and edges, where the nodes are activities and the edges define a possible sequence. The callable business entities are directly assigned to the activities. Please note that especially for built-in processes the sequences of the different activities is not really fixed, the execution of activities at runtime may be in any order and activities may be repeated. In those cases a normal sequences of activities represents a best practice for this type of process. In cases of specific application constraints – typically defined within the business logic of the application – the sequence is not changeable. In a future version an additional entity constraint between business activities describes this artifact. This will clearly show where process flexibility is given and where not due to the defined constraints.To map the built-in process executed to the process model, an activity binding is required to relate task events carried out to activities at runtime. Process determination rules, a specific type of business rules, are associated to the activity binding. At runtime, the rule is evaluated based on the content of the task event. The result is an activity. The task event identifies the executable business entity and thus also the callable entity.Note that the activity bindings are not required to model a process; they are only needed to observe process instances executed in the system. A logical unit of work, LUW, is an inseparable sequence of operations which must be executed either in its entirety or not at all; within the SAP system LUWs guarantee the integrity of all data on database and business level. Even though the LUW is initially a technical concept, it reaches up to the business perspective, because it determines the granularity of the individual business processes steps.The term UI transaction is used to separate the transaction as defined in table TSTC from the database transaction. In this context we will always refer the transaction that constitutes a UI application built for user interaction.It will be necessary to build, deliver and amend process models on all levels: SAP core, industries and countries, partners and customers.Activities can also be executed by the system; this can be considered as “automated” activities.Business rules are not a process entity. At this point they can be thought of as something defined in the BRFplus (Business Rules Framework Plus).

38

We have to consider the meta model here.The process definition must be set up by the customer (business process expert) using transaction POC_MODEL. This is based on facade entities.The assignment of the facade entities to the runtime is content that is delivered by SAP; at this point of time content is not complete and the runtime assignment content may need to be completed on project basis. This is generally easily possible since all related tables are E-tables. Even if SAP delivers the appropriate content existing implementation will not be affected.

39

SAP delivers some sample customizing, which is by default only available in client 000– Sales Order Processing– Purchase Order Processing

You can start with them, and copy, or enhance them, or create new process definitions.

Generally you can start with a rough definition of your process and refine it later then.Accoring to the steps you want to observer, and the Process KPIs you may want to calculate (and thus use for threshold monitoring) you may need to add activities to the process definition.

40

You can create a Process definition by using the Transaction (POC_MODEL)Provide the following information for process modeling:

– Process Name– Initial version

SAP advises to use ascending numerical values for the version. While technically not required, it will make handling and working with versions easier for the users.The “current version” is the version that is being used for new process instances that are created. Current version should be an active version.If there is no active version, the highest active version will be used as current version. A warning will be written to the application log.For existing process instances the current version has no effect.

- For a process Definition you can create multiple versions based on its technical objects (e.g. callable Business entities, related Process chain information, etc. )

- From a Monitoring perspective, you can enable multiple versions for monitoring. Only the Current version is considered for process monitoring.

Level of Logging :- Standard Logging : Use this option, if you would like to Monitor this

process in real-time.- No Logging : Use this option, if you would like to create process version.

But, not interested in its real time monitoring.- Extended Logging : Use this option, if you are interested in the detailed

log information of a process.

To activate a process definition for logging:– Activate the Process version for Logging– Provide the mode of logging as ‘Standard logging’

The definition check (POC_MODEL_CHECK) checks that there is an active version.

41

A process can have multiple start and end points. Based on your business scenario, you can define the start and end points for a process.Note : Do not activate start and end points for every activity in a process.-Start point: defines at what point new process instances may be created-End point: relevant for process status calculation

By assigning Tasks to activities you create a connection between the activity, and the application.The Tasks are part of the Process Façade, and represent application events. Many Tasks are pre-delivered by SAP.

Assignment of Callable Business Entity (CBE) to an activity indicates the mode of execution of an activity. Example: If ‘CREA SO’ activity is assigned with a Callable Business Entity ‘ VA01’ then it indicates that, Creation of sales order is executed via the transaction VA01. At this point the assignment of the CBE is for documentation purposes only. It does not affect runtime, i.e. logging, at all. The event will be logged regardless of the transaction that is originates from.Two other types (SOA Services and Workflow) of Callable entity types are allowed for a process definition in this release as well.

In case of federation (when process flows across different process definitions) you have to define the integration points for process at the activity level.Two type of Integration Types(Message(MSG) and RFC) can be used for process integration at present.You have to define the Direction of the Integration (IN and OUT) to know the process flow in case of federated processes.If the federation information is put into the model, the system is able to federate individual process instances to an end to end instance of a process chain. This is

42

The sequence information is for presentation purposes only and not used at runtime. Process Observer always monitor the actual flow.

The sequence information can be used for presentation of the logged information. Therefore SAP recommends to provide a sequence flow that covers the “best practice” flow.If no sequence data is available, a default sequence is assumed and used.

Note: There is no plausibility checking of the data. The system will not detect if the sequence is incomplete etc.

43

(*) The parameter is set using transaction POC_ACTIVE; it can be used e.g. to de-activate all process logging in case of problems and will stop the queues and logs to be filled.

Available Log Levels:- No Logging- Standard Logging: Only the process and its related events (tasks) and activies are logged.- Extended Logging: The process will be logged, and all other events (tasks) that occur on Business Objects assigned to the process defintion.

44

Process Definition Check Report POC_MODEL_CHECK also gives you informatin about versions and activation status.

45

Transaction POC_MODEL_CHECK provides a consistency check.The type and extend of checks is constantly improved, it includes:•check if the process definition has at least one start activity; this is required, otherwise no instances will be logged•check if the current version is set on header level of the process; this is optional, otherwise the latest (highest value) version will be used•check if all activities have – through tasks - BOR events assigned; if no BOR events are assigned the activity will probably not be logged; if the task is raised through the (external) API or the activity is only added for documentation purposes this can be disregarded•check if the assigned BOR events are activated for process monitoring; this is required: if this is not the case, the BOR event will not be monitored; this type of problem is almost always an inconsistency, unless specifically set up this way; usually this issue can be resolved by re-saving the process definition or by running a report to fix this (POCR_UPDATE_BOR_EVENT, not available in all SP levels)•[additional checks; TODO: Complete]Some warnings indicated may not necessarily be fatal.Some checks about the overall system status are added (see chapter „Activation“ for details):•If the business function has been activated, which is a pre-requisite for the processing of events•If process observer is activated using the general switch in POB IMG •If the main report for processing of BOR events, API events and thresholds has been scheduled 46

[Advanced]The control table is POC_C_BOR_EVT.Use report POCR_UPDATE_BOR_EVENT to fix incosistency (the report is not available in all SP levels), or change and re-save a process definition, if possible. All events will be updated, not just those for the changed process definition. Inconsistency will be most common after transports.Report POC_MODEL_CHECK checks if the control table contains alls events needed for the process definitions checked (see: check process definitions).

In the case of splitting / creating new events in BAdIs based on BOR events you need to be careful. If the required BOR event is not directly assigned to an active Process Definition, it may be deactivated in the table of relevant BOR events for Process Monitoring, and therefore not processed any more.In this case you can either update IMG activity „BOR Events Relevant for Process Monitoring“ manually, or add an entry for depended tasks in the Process Observer Facade.

47

[Advanced]Process definitions are stored in C-tables and transported through the standard ABAP correction and transport system.Not transported, but generated with each change is the BOR Events relevant for process monitoring table and the registry data.Activation information for POB as a whole, process definitions and versions is also transported.If definitions or versions need to be activated or de-activated when no changes to the the standard tables are possible (e.g. in the production system), the check report (transaction POC_MODEL_CHECK) provides the possibility to do so.

48

To check the process definition use transaction POC_MODEL_CHECK

49

You can view the Process Definitions created by the users in your system (POC_VIEWER)

You can search processes by using the following attributes– Process Name– Version– Time stamp– User name

50

• Activity tab displays the sequence of activities to be executed with the start and end points of the process• Count KPIs Tab displays the configured COUNT KPIs for the process• Duration KPIs Tab displays the configured KPIs related to the Lead time calculation for the process• Classification KPIs Tab displays the KPIs involved in a certain kind of group. Example : Threshold value assigned to some attribute use in the process.• Status Tab displays the user defined status mapping with the default system Status.

Note that you have flexible options to display the details of the definition using the standard ALV features, e.g. change the list of fields displayed.

51

Details about federation are given in section ‘Advanced Topics’.

52

We have to consider the meta model here.The process definition must be set up by the customer (business process expert) using transaction POC_MODEL. This is based on facade entities.The assignment of the facade entities to the runtime is content that is delivered by SAP; at this point of time content is not complete and the runtime assignment content may need to be completed on project basis. This is generally easily possible since all related tables are E-tables. Even if SAP delivers the appropriate content existing implementation will not be affected.

54

Façade layer content is maintained through POC_FACADEIn general, SAP should provide complete content for the façade. If content is missing, the customer may need to add missing content.

The SOA BOs contains the complete list of all BOs with their generic (English) descriptions. You can add own entries here in the customer name space.

The Business Object Types contains the list of BOs that are available in the façade and thus can be used to create tasks that can be used for process definitions.To add Business Object Types, it needs to be in the list of SOA BO Types.

Task type can be re-used, they correspond to actions performed on Business Objects; descriptions of tasks will refer to the task descriptions, not to task type descriptions, thus a task type “Convert” could be used for a “Submit” task; for readability appropriate tasks should be selected; new task types can be created, if this is preferred.

Most of the time new Tasks will be created. The tasks are the most relevant object of the façade layer. Since the task is a composite of BO and Task type, tasks must always be BO specific and the BO can be – and actually is at runtime - derived from the task. So the BO should be carefully chosen.Task can be defined as Item Level Tasks in the process facade. For the item level task see <Item Level Tasks> and <Item Level Support>.

The Callable Business Entity can also be added optionally to the process definition (see Create Process Definition). This serves only documentation purposes. All tasks (events) raised within a given CBE can be maintained against the CBE.

For missing content of standard objects, you can contact SAP and ask for the content to be created. That way you avoid using content in customer namespace. Technically if SAP creates similar content later, this will not conflict with customer created content, even if a BO exists twice in the table of BOs or events are mapped to multiple tasks (standard and customer).

All tables have a customer name space (Z*).

55

This maps BOR events from the application to the tasks; thus a connection from application event to process definition is given via the task.Note: tasks do not necessarily have to be mapped to BOR events. When using the direct event interface for Process Observer, application can directly raise events as tasks.

You can maintain the BOR instrumentation by using Transaction ‘POC_CUSTOMIZING’ and navigating to ‘ GENERAL SETTINGS BUSINESS OBJECT REPOSITORY INSTRUMENTATION’Navigate to ‘Maintain BOR Instrumentation’ or use transaction POC_BOR.

1. Here map the Business Object with its corresponding BOR event. E.g. the Sales order business object (114) is mapped to BOR object (BUS2032)

2. Map the BOR events to the tasks. E.g. The SO BOR(2032) is mapped to tasks ‘CREATED’ and ‘CHANGED’

3. The same is supported for events that are modeled using ABAP classes rather than BOR. Note that this does not cover any ABAP event raised using the ABAP statement RAISE EVENT, but only those events that are supported by the event runtime, similar to BOR events.

Multiple assignments are possible. This may lead to unexpected results, at least for visualization.

Note that to find out what BOR events are raised by you application during execution you can use transaction Display Event Trace (SWEL) to trace BOR events. You need to activate the trace in SWEL or using Switch Event Trace On/Off (SWELS).

Initially the main instrumentation of the process observer is through BOR events. A large number of BOR events exist, about 7.000 in the Business Suite.What we call “BOR events” are, accurately named, “BOR event types”; but since the BOR currently calls the “event types” “events” most of the time, we are using here the terminology as used in BOR and associated documentation; it should be clear from the content when “types” of events are referred to and when “instances”.In SAP SCM 7.0 events 548, BOR-objects with events: 165; in SAP CRM 7.0 events 1.343; BOR-objects with events: 303; in SAP SRM 7.0 events 830; BOR-objects with events: 188; in SAP ERP EHP4 events 4.223; BOR-objects with events: 1.007.

Ths same as for BOR events applies to IF_workflow events (class-based events).

56

[Advanced]The previous business object (BO) must be determined for each BO, unless the BO is (always) a starting object of the process.For the direct event API of process observer (see Advanced Topics section) the application is supposed to provide the previous BO information in the event.A business object by itself is always considered as a possible previous BO, and thus does not need to be added explicitly to the previous BO list.

For BOR events:- The BAdI can be found in IMG: Business Add-Ins -> BAdI: Previous Business Object Determination- IMG path to map previous objects from the BOR container: Business Object Repository Instrumentation -> Business Object Repository Instrumentation -> Map Previous Objects from Business Object Repository Payload; the view is POC_V_MAPPREVBOR.Note that the elements of the event container may be structures, thus a field name is sometimes required. The type (data element) of the target field must be put here redundantly for technical reasons.- DRB originally supports archiving. DRB can have certain runtime issues, i.e. it is not very fast depending on implementation of the relevant DRB function module. Event container content should be used if available and if performance is relevant.DRB may return multiple “related” BOs; customizing is available to control which of these BOs is used by setting a priority against the BOs.POB delivers a tool (TA POC_DRB) to call DRB directly for testing purposes.

[TODO: Add example] 57

[Advanced]BO level logging is an expert activity to support the process of discovering BOR events. To use it a throughout understanding of the basic functionality is required.You can activate BO level logging in IMG chapter „Activate Business Object Type Log” (POC_V_BO_LOG).You maintain the BOR events to be monitored in IMG chapter “Check Process Monitoring Events for Bus. Object Repository” (POC_V_BOR_EVT), otherwise the BOR events are not put into the BOR event queue.Note that BO level logging will create orphaned activities in the process log and you need to use special means to access the

58

The simulation report is POC_SIMULATION and can be started through transaction POC_SIMULATION.

The simulation can also start up a simulation model maintained in a table, choose option „Simulation ID“ (not available in all SPs).The table to set up a simulation model can be accessed through view POC_V_SIM (SM30) .

The result of simulation logging can always be viewd in the Process Monitor.

59

Simulation model allows fast check of the logging according to the process definition.Previous BO information is required to ensure the logging of the process chain.

60

The simulation report is POC_SIMULATION and can be started through transaction POC_SIMULATION.To write complex simulations, study POC_SIMULATION, create your own report and re-use include POC_SIMULATION_MAIN. The macros to use are explained at the beginning of include POC_SIMULATION_MODELS. If you need to go even deeper, you can also copy POC_SIMULATION_MAIN.Do not output to screen if you great large amounts of data.Show runtime will help you to determine processing times of events in case there are performance issues in process observer. For details see the performance considerations (TODO).

[TODO: Provide complex example with random lead times]

61

Screen shots may be taken from different versions and SP levels of the product.

63

Note that simulation allows temporal offsets, so that duration KPIs can be simulated in a sensible way, including alerting. For details on simulation see <Simulation>.

67

Cross instances KPIs like averages are expected to be calculated using BW or HANA.ODPs are available from 731

68

Count KPI : This KPI is used to count the no. of occurrences of an activity during the real time process run.

The ‘Determiner’ is the Qualifier used to provide the specific condition of the activity occurrence, values supported are “Before first” and “After first”.

KPIs can be measure between tasks and activities. Generally KPIs should be defined between activities. For item level activities, task level KPI definition is useful(Activity level KPIs have been provided with a later SP: 702SP08 fully, 07 partly).

Non-Aggregated will create one count per business object instance, so if two sales orders are created and changed, if Non-Aggregated is set, two counts will be created for this process instance (e.g. 4 changes to the first, 5 changes to the second sales order); if the KPI is aggregated, only one count is created (i.e. 9 in this example). This is particularly useful for item level support.

Example 1 – Simple, no task level:Process A has five activities (A): A1; A2; A3; A4; A5.

In process instance A, the activities occur in the following order:

A1 -> A2 -> A5 -> A4 -> A5 -> A4 -> A5

Process A has a KPI defined as follows: Count how many times A5 is executed after first A4 is executed.

In this case, A5 is executed 2 times after A4.

Process A has another KPI defined as follows: Count how many times A5 is executed before first A4.

In this case, A5 is executed once before first A4.

Example 2 – extended, task level KPIs:TODO

70

Duration KPI : This KPI is used to find the lead time between two activities during the real time process run.

The KPI is supported by the Qualifiers for both activities.

For task level support see duration KPIs.

Example 1 – simple:Process A has five activities (A): A1; A2; A3; A4; A5.

In process A, the activities occur in the following order: A1 -> A2 -> A5 (t1) -> A4 -> A5 -> A4 (t2)-> A5

Process A has a duration KPI defined as follows: Calculate duration between first occurrence of A5 and last occurrence of A4. The time calculated is t1 to t2.

71

You can later use the classifications for filtering processes, as status variables, or for aggregation in analytics environments.The BRFplus rule should return one of the classificateion codes defined in the ‚classification for processes` defined list. ‚classification for processes` contains a code + description.

Especially during the calculation of classification KPI you can use the BRFplus rule to create interesting side effects, e.g. Trigger workflows (push tasks to processors), call ABAP function modules, alerting etc.

As for all rules, first „Create BRFplus Rule“, then „Save“ then you can „Edit BRFplus Rule“.BRFplus offers many options to model a rule, including tables and customer specific function modules.BRFplus is not available in 701.

72

[Advanced]Aggregated („default“) KPIs lead to one valuation of the KPI per process instance. In case there may be multiple objects that start the KPI calculation (for example multiple Sales Orders following an Inquiry), it may be required to calculate the KPI values for each starting object separately, e.g. the duration from sales order item creation until delivery for multiple sales order items of a given sales order. To calculate KPIs for multiple items in parallel, the non-aggregated calculation is definitely required.

For this topic also see the <Item Level Support> in chapter <Advanced Topics>.

Non-aggregated KPIs are available from a later SP delivery.

73

Process Observer detects the violation of predefined thresholds. Thesholds can be set for process definitions, or for individual processes using BRFplus rules. Following the violation a BOR event is thrown indicating the violating process. The BOR event can be used to trigger automated reactions like launching a workflow, calling a service or sending an event to NW BPM, or contacting a person using email, SMS, ... using the alert framework.

74

Thresholds have been added with a later SP (731 SP02 for full functionality, 702 SP08).

Threshold alerts are raised by report pocr_track_threshold, that is executed as part of the main report that should be scheduled to run in background and that also processes the queues (POCR_MAIN_QUEUE); alerting happens at the end of the processing, after the queues habe been processed. The report can be executed separately and can also be scheduled separately. For details see <Activation>.

A category threshold is reached if the value is reached exactly, there is no „greater than“ comparison.

75

[Advanced]The alerting framework is completely independent of POB.For a simple set-up see this guide, for more advanced topics look up details on the alert category.Transaction (TA) ALRTCATDEF to create an alert category.

76

[Advanced]Event Type Linkages is TA SWE2.Enter the event for BOR Object Type POCPROCESS and event Threshold_Reached.Set the receiver type to the alert category to be used.Use receiver function module SALRT_CREATE_VIA_EVENT to use the alerting.Make sure to activate the linkage!You can test by raising events using SWUE.

77

Monitor Processes: Configure the processes in a business scenario for end to end monitoring

Prerequisite: You understand process definitions and its entities.

79

TA POC_MONITORThe delay between an activity/task being executed and it appearing in the process viewer depends on the scheduling of the reports scheduled to process the event queues.Access to instance data is controlled through authorization (object POC_AUTH)Generic Object Services (GOS) are available in Dynpro, not in WDA. For details on GOS see <GOS>.Web dynpro UIs are not provided for the lower releases (Business Suite 7 i2010 and below).

82

The process monitor (POC_MONITOR) allows you to search for process instances (not activities or tasks).The process definition is defaulted from set/get parameter POC_PROCESS_TYPE_ID; you can pre-set that using “Own data” across sessions.The default time period is the previous hour.The maximum number of results must always be limited.The advanced search allows a number of additional parameters.The business object ID is converted to a proper format, if the business object type is provided, e.g. if business object type 114 (sales order) is given, a search for business object ID “1000” will actually search for a field value of 0000001000, which is the internal representation of the business object. Thus a search for business object type 114 and business object ID 1000 may find a process instance while a (seemingly less strict) search for only business object ID 1000 may at the same time NOT find an instance. (Conversion has been added with a later SP).Wildcard search (* etc.) is not supported for the search options.

83

You can navigate to the process definition from the list and the details screen by using the <Process definition> button from process monitor. Process definition provides the overall view of the process modeled for monitoring.If only one process instance is found, the system immediately shows the detail screens.

The list shows the technical status, the user status and multiple additional fields are available through ALV customization of the list (as for most lists).Double-click to see details.

84

Note that you have flexible options to display the log using the standard ALV features.

85

ALV will show the activities in a list ordered by some parameter, by default by execute date and time. The “Related Activities” shows the actual predecessor and successor, which is needed to show more complex relationships, e.g. a process forking into two sequences: an activity would have multiple successors then.

Related activities can also have relationship inbound and outbound, that will be further explained later in <Federation>.

86

Many transactions support the generic object services (GOS).As an exception, for transaction VA02/VA03 GOS services are only available if the set/get parameter SD_SWU_ACTIVE is set to X (this is for performance reasons, see note 598073).

88

ESH models are defined for process instance search. Authorization checks are supported.

To setup create connector for ESH model ‚Process ID‘ (0POC_PRC_ID) in transaction ESH_COCKPIT.

Search using transaction ESH_SEARCH. Navigate to Process Monitor from result list

Available from Business Suite Foundation 731 (e.g. ERP 6.0 EhP6, CRM 7.0 SP02). Requires TREX, can be combined with BWA.

89

Business Suite Foundation 731 is part of Business Suite 7i2011 shipment and comprises for example SAP ERP 6.0 EhP 6, SAP CRM 7.0 EhP 2, SAP SCM 7.0 EhP 2, SAP SRM 7.0 EhP 2

94

These are minimum requirements. Higher release numbers of BI content or SPs also contain the BI content for Process Observer.

We recommend to use the latest BI Content SP available for your SAP BW installation.Depending on the BI Content and SP level you are using, there are different amounts of predefined content delivered for Process Observer.

95

• Process Observer customizing transaction: POC_CUSTOMIZING

• Uses Content Bundle ‘0POC_BW’ in BI Content Activation Workbench

• Alternatively the datasources can be activated manually via RSA5, BI Content can be activated in the BW system using transaction RSORFor further , see IMG documentation, and note 1694446.

96

The Process KPI datasources provides Process KPI values in a generic format: the ‚process definition ID‘ specifies the KPI , the value is contained in a separate field.Depending on the KPI category, as specified in the KPI definition, the value is contained in a different field, having different technical properties:- Counter Value- Duration Value + Unit- Classification Value (= Code)

For details about RDA enablement, see note 1694446.

97

In backend: transactional data

Assignment of Activity to KPI data sourceEspecially for non-aggregated KPIs, the data sources contains activities or tasks related to the KPI values:- counts: counted activites or tasks- durations: start and end activites or tasks- classifications: relevant/classification activity

Previous Task and Business ObjectsContains document flow information (previous Business Object) and process flow information (previous task)


98

In backend: Master Data / Customizing Data

RDA and delta handling are not relevant for these data sources.

Realized Process Chain assignment:Assignment of a E2E process ID to a process definition ID.

Integration point and integration type:Represents RFC, iDoc or service based communication between systems.

99

In backend: Master Data / Customozing data

RDA and delta handling are not relevant for these data sources.

100

Info Providers for Process Observer in BW: they contain data and are linked to data sources, or to other info providers.

101

KPI Data flows from Datasource via DSO to InfoCube, or from DataSource directly to Virtual CubeMultiProvider bundles InfoCube and VirtualCube

Key figures are: - Duration Value 0POC_KPI_CN- Counter Value 0POC_KPI_DUNote: default aggregation is by Process Instance.Other aggregation e.g. by Business Object ID will have to be specified explicitly in the queries.

Classification will be transferred as a characteristic.

102

Additional queries are provided to support the sample dashboard:

0POC_MP01_Q0001 - POC: Top/Bottom Process KPIs0POC_MP01_Q0002 - POC: KPIs by Quarter0POC_MP01_Q0003 - POC: KPIs by Month0POC_MP01_Q0004 - POC: KPIs by Week

You can use the Report-Report Interface (transaction RSBBS) in SAP BW to navigate from query to query, or to web addresses, or to transactions in the SAP system.

103

Select year, aggregation, access method (direct via virtual provider, or replicated via BW)Diagrams are interactive: select point in diagram to display Top or Bottom processes in detail

view

The process definition ‘SALES ORDER PROCESS’ is delivered with:- ERP 6.0 EhP6- ERP 6.0 EhP5 SP 06

104

Input for process definition in $C$7: <LogicalSystem>/<ProcessDefinitionID>The logical system is mandatory here, as the process definition ID is considered to be unique in the local system only.

105

Lab-Preview of O2C Delivery-on-Time dashboard.

106

RDA = Real-time Data Acquisition


107

• Uses Content Bundle ‘0POC_ODP’ in BI Content Activation Workbench

108

ODPs correspond to the InfoProviders in BW.BI Queries can be built on top.No sample queries delivered up to now.ODP definitions are created based on Search Models in transaction ESH_MODELER.

ODP based analytics can be combined with a BWA for improving performance. BWA con be combinded with TREX for Enterprise Search.To use BWA create Search Object Connectors for Analytics in transaction ESH_COCKPIT.SAP BusinessObjects Explorer can be connected to BWA indexes for Analytics.

More information about ODP in SCN: SAP Operational Analytics<http://www.sdn.sap.com/irj/bpx/index?rid=/webcontent/uuid/40bdb7d7-8ea6-2e10-5c93-ebee641e5cf9> See also: http://scn.sap.com/community/embedded-analytics

109

http://www.sdn.sap.com/irj/bpx/index?rid=/webcontent/uuid/40bdb7d7-8ea6-

http://scn.sap.com/community/embedded-analytics

Corresponding BW query is: 0POC_MP01_Q0005 – Process KPIs

110

Process Observer data sources are released for consumption by external consumption (ETL interface).

You can do analytics on top of Process Observer data in a SAP HANA system.

You can extract Process Log information via existing data sources for Process Observer.

Option 1: via BusinessObjects DataServices (via ETL interface)Option 2: via Direct Extractor Connection for SAP HANA

Find further information here on the different options to extract, or replicate data to SAP HANA:

SAP HANA Installation Guide:https://websmp203.sap-ag.de/~sapidb/011000358700000604562011D

Direct Extractor Connection DXC´https://websmp107.sap-ag.de/~sapidb/011000358700000421852012E

111

https://websmp203.sap-ag.de/~sapidb/011000358700000604562011D

https://websmp107.sap-ag.de/~sapidb/011000358700000421852012E

Trigger-based data replication:https://websmp101.sap-ag.de/~sapidb/011000358700000604912011

Log-based datareplication:https://websmp106.sap-ag.de/~sapidb/011000358700000258522012

112

https://websmp101.sap-ag.de/~sapidb/011000358700000604912011

https://websmp106.sap-ag.de/~sapidb/011000358700000258522012

Function Module POC_RAISE_EVENTLocal or Remote Call (Synchronous RFC) Mass-enabledUse facade definitions directly (no BOR semantics) to define the eventPredecessor object information in API required to allow process correlation

(same BO does not need to be filled in as predecessor)

The API is fast, because it only puts data into buffer, the performance overhead is for communication, not processing.

It can be called remotely, or locally, as alternative to using BOR Events (for example, if BOR object and events are not yet available).

Through the Event API, systems that do not have Process Observer locally available, here called „client systems“, can also participate.This may be non-SAP systems or SAP systems of lower releases or SAP systems where for some reason Process Observer is not set up.This requires the external system to provide the events. The process log is available in the suite system and only in local (to the suite) UIs.Limitations of this approach are obviously availability of events in the client systems and overall performance considerations; even though the API is capable of bundling, volume may be a limiting factor.

As a local alternative to BOR Events when no remote is required, you can use method RAISE_EVENT of class CL_POC_EVENT_CONNECTOR instead of using the function module. You need to create an instance of the class using the GET_INSTANCE method. But it is a generally a better approach to throw BOR eventslocally, since these will be processed at the same time as already existing events; otherwise if related BOR events and events passed through the external API happen in short sequence, it is possible that there arerace conditions where the processing order of the events is inverted.

The external API is later SPs (701SP10, 702SP07; you will need note 1689819 until 701SP11, 702SP09).See note 1737693 for details on how to use POC_RAISE_EVENT.

117

The Event-API for Process Observer can be called remotely via synchrounous RFC call. Internally this is a simple function module call, or method call.A table of events lt_event is created and used as input to the RFC module.A single event contains information about the event (task) type, the business object (type and id), the callable business entity (e.g. transaction), user, execution date and time, and logical system.For federation across systems the kernel transaction ID should be added to the event. Document flow information should be given in the form of predecessor object information to the event. This information is used to create the process instance chain in the process log.After the execution of the function module, the events are stored in a buffer table and are processed asynchronously.

For using the RFC module in systems not containing process observer, see note 1737693.

118

Performance needs to be considered in all Remote-Event Scenarios.

119

1. Application knowledge may be necessary to determine the appropriate changedocument.

2. To extend an existing BOR object by an event, you have to use the BOR extension concept to create a new object as a subtype, add the new event there and optionally delegate from the original object to the new object

3. To link to a change document, use TA SWEC4. Optionally you can restrict the event to be raised to certain conditions

121

The Wizard for Event Linkage (SWU_EWCD) will create a new event for the existing business object.This automates the standard process to extend an existing BOR object:•Create a new subtype of an existing BOR event•Add an event to the new BOR object•Create a substitution of the original BOR object to the new BOR object; this will lead to any event raised against the new object to appear to be raised on the original object (for runtime purposes)These steps effectively extend the original BOR object by a new event.

122

Create the event linkage in SWEC.This will lead to the event being raised whenever the change document is created.

123

You can restrict the event raised by the change document to be raised only conditionally. Call the Field Restrictions to limit and call the Condition Editor and enter the condition. It is possible to create complex rules looking at multiple fields and their values.Rules may take some runtime, but since this is executed in background this willnot affect dialog performance, unless there is a large number of change documents to process within a given period of time.

124

Example: Monitor Field Value ChangesChanges to the requested delivery date (KETDAT) of a sales order are to be monitored. First, an appropriate event needs to be found.Sales order is BOR object BUS2032. The business object builder (SWO1) will show that there is an event "SalesOrder.CHANGED" for object BUS2032. As expected, there is no specific event which indicates the change of the particular field "requested delivery date".The event linkage for change documents can be used here.

There are two things that have to be done.The first thing you is to create or model an event that is raised specifically for your purpose; this is all standard BOR/workflow best practice and may be quite familiar to anybody using that:(1) Create a business object, e.g. ZBOR2032PM, in BOR inheriting from the relevant business object, in this case BUS2032(2) Create your specific event, in this case "REQ_DELIVERY_CHANGED" against the new BOR object ZBOR2032PMOnce that is done the new event is created.The event needs to be raised now.(3) In transaction Event Linkage for Change Documents (SWEC) the new event has to be entered against the change document object "VERKBELEG" (meaning “Verkaufsbeleg” which is German for "Sales Document")(4) Finally, you a "Field Restriction" has to be added so that the event is not raised every time a change to the sales order happens, but only when the value of requested delivery date is changed.

To do (almost) all of that you can the Wizard for Event Linkage (SWU_EWCD) can be used. Enter the object type, here BUS2032, on the second screen. The third screen defines the new BOR object - step (1) above - and has a number of fields, the subtype would be ZBUS2032PM, object name and name could be SalesOrderAdd, some description is needed and a program name, usually by convention the name of the subtype, here ZBUS2032PM. Application can be left set to “*”, an appropriate package must be chosen (or $TMP be used for testing).

Now an event has to be defined, which is step (2) above.

Finally, link the event with the change document, step (4) above.

The final screen will complete the wizard.

Now call the Event Linkage for Change Documents (SWEC) and call the Field Restrictions to carry out step (4) described above, call the Condition Editor and enter the condition.

It helps to look at the appropriate table (in our example VBAK) in data dictionary (SE11) to see the descriptions of the many fields a sales order has to offer.

What is described here is, obviously, only an example. It should be simple to address other fields or combinations of fields using the events for change documents and the condition editor as shown here.

To fully utilize this event a separate task for the change of the field in the sales order has to be created in the façade (TA POC_FACADE). You can create your own task type Z01 Field change: Requested Delivery Date and the add task 114 Z01 Change requested delivery date (of sales order). You can also re-use any existing task type, that is not being used with the current business object; this is the preferred approach.

Then the new event has to be mapped to the new task in the View Cluster For BOR Instrumentation (TA POC_BOR).

The new task can now be used in process definitions and at runtime the event will be mapped to that task and behave as expected.

125

Example for the usage of field level changes: Reporting on field changes of some key fields of the sales order.

126

When Change Documents are written, BOR events can be raised for the use of logging field-level changes with process observer.In the upcoming version of process observer change information will be made available automatically as a generic event. Applications can then simply use customizing to map change information to Process Observer task (BO+Event) information.

127

„Item level“ actually describes what technically is „sub-BO“ support.The ID of objects stored consists of BO Type, BO ID and an Item ID.The process log can use this to differentiate between objects on item level; this can be used for previous BOs determination, where the predecessor of a line item can be another line item and for KPI calculation, where an aggregation may not be desired if item level activities are to be measured.

You may want to define different tasks for Item Level, and for Header Level.If you are only interested in Item Level Information, you do not necessarily need a header task.

129

1:1 assigment is what you often do, if you only care about events relevant for the entire instance.

If more than one task is assigned to an activity, then the activity will be logged, if any of the tasks is observed.If, in the tase of multiple assignments, and the flag ‚Additional Task‘ is checked, then the activity is not logged, if only the additional task is executed. It is only logged, if at least one non-additional (=main) task is executed.In the details of the log in the monitor however, also the additional tasks can be seen.

In the sample above, there are only 2 activities defined:- Create Sales Order (30)- Update Sales Order (35)

The header task (Create or Update Sales Order) is always defined as non-additional (= main task), so we log the activities, when they are executed.To get information about item level, we add the item level tasks for Create and Update of Sales Order Items. The Create of items can occur in both activities (multiple assignment), while an update of the item is only possible in the update of the Sales Order. The item tasks are marked as additional tasks, so we make sure they are logged only in the right context of the (header) BO activity.130

KPIs on item-level definitely occur multiple times within a process instance for different BO-ID/Item-Ids. Therefore non-aggregated calculation should be selected.

If you do not have 1:1 relationship between activities and tasks, you may rather want to use Tasks for definition of Process KPIs than Activities.

131

Generally item level BOR events will not be available. Examples of items are sales order (line) items and line items of an outbound delivery. Technically any sub-object of a BO can be considered a „line item“; it needs to have its own ID, which is unique within the BO.

In the save BAdIs of application you can typically check, what changes have been done and create events using the direct event interface of Process Observer.If you have the information, you can use these BAdIs also to create events about field changes, alternatively to using events based on change documents.

It is also particularly useful to use change documents, since they (often) contain item level information that can be used. Otherwise generating the appropriate tasks can be complex.Finally, existing programming exits, like save-BAdIs can be used to explicitly create item level events. These events have to be modeled in BOR and assigned to facade level entities in POC_BOR.

To create events on item level, BO level events have to be examined and, if applicable, converted into item level events. E.g. a „change sales order“ event may be raised and further evaluation detects that the change sales order consists of the change of two line items and the creation of a third line item. This „evaluation“ will generally be implemented in the appropriate BAdI in the BOR connector. Note that one BOR event can thus lead to multiple tasks.

In the case of splitting / creating new events based on BOR events you need to be careful. If the required BOR event is not directly assigned to an active Process Definition, it may be deactivated in the table of relevant BOR events for Process Monitoring, and therefore not processed any more.In this case you can either update IMG activity „BOR Events Relevant for Process Monitoring“ manually, or add an entry for depended tasks in the Process Observer Facade.

132

An existing application exit can be used to create specific item level events.Obviously the exit must support the requirements.The direct connector („Event API“) can be used to create item level events.

133

In many cases it is possible to use an event raised through the change documents. It is possible to put the complete change document, that generally includes also all required item information, into the event container. The transformation can then be executed based purely on the event container.See section about Change Documents as Event Sources.

134

The original event is a standard event and the transformation may require database access to read additional data. The transformation can be implemented in BAdI POC_INSTR_MAP_EVT_TASK of enhancement spot POC_INSTR.

In the case of splitting / creating new events based on BOR events you need to be careful. If the required BOR event is not directly assigned to an active Process Definition, it may be deactivated in the table of relevant BOR events for Process Monitoring, and therefore not processed any more.In this case you can either update IMG activity „BOR Events Relevant for Process Monitoring“ manually, or add an entry for depended tasks in the Process Observer Facade.

135

The process log above shows the standard processing, but does not support item level KPIs. Tasks are equivalent to activities in this example.Below the same process using a transformation of the events raised by the actual process being executed; oThe item tasks can be mapped to the same activity as the leading task, shown here or to separate activities.See the following page for the KPI calculation.

SO: Sales Order OD: Outbound Delivery

136

KPIs can be defined on task or activity level.See also <Non-Aggregated KPIs> in chapter <KPIs>.SO: Sales Order OD: Outbound Delivery

137

You should always try to define simple processes as they areEasy to understandEasier for tracking changesReusable

Local federation : Connects the Processes in a single System/client.Remote federation : On each system an instance of Process Observer is runningand logs the local processes.

Remote federation connects the processes modeled across systems/clients.

Mixtures of both kinds of federation are allowed.

Note : The scope of federation is limited to SAP systems only in this release.

When connection a SAP or non-SAP system to a Process Observer system using the remote event API, and the remote events are logged in the same process instance as the local events, we don’t call this federation.

139

For remote federation the registry plays an important role. One of the Process Observer systems is configured to be in the role of the Process Registry.The process registry containd information about Process Definitions in all local systems, and how they are connected together via Realized Process Chain Definitions (E2E Process Definitions).

EWM = SAP‘s External Warehouse Management – this could also be a third partysystemThe registry is part of process observer; any system containing process observer can serve as the central registry.

140

Process Facade is used during runtime to access the Process Registry and other instances of Process Observer.

The Process Registry contains definition information about E2E processes (Realized Process Chains) and integration points. So systems for E2E federation can be determined.

141

Settings in transaction Process Definition (POC_MODEL)Assignment of realized process chain needs to be done for all the processes

participating in the business scenario.

Local Federation connects different Processes in the same Process Log, but having different Process Definitions

Assign same Realized Process Chain Definition (=E2E Process Definition) to different local processesFederation in monitor should happen automatically using the predecessor BO information

142

Connect different Processes from different Process Log (Cross-System Federation)

(this required different process observer instances running)

Assign same E2E Process ID (RPC-ID) to different local processesMaintain Integration PointsSame Kernel transaction ID is to be stored with sending event and receiving task event (transported with message passport for IDOC, RFC, Enterprise/Web Service)Federation in monitor should happen automatically using the transaction ID

- ‘Logical’ System: use the same names in all Process Observer installations.- RFC-Destination can be created by the using the transaction SM59.

143

IMG Activity General Settings – Federation – Check Integration Point Type Code: list of available integration point type codes

You need to define the IN and OUT integration directions for the interfacing activities of two processes to be part of federation by assigning integration points.For one integration point in a remote federation scenario you should have outbound and one inbound assignment for one integration point.

Integration direction:In : If the process flow enters to the Process with used activityOut : If the process flow moves out of the Process with used activity

Note that the integration point type and the integration point ID define the integration point; so to link two processes in two different systems, the same integration point has to be defined in both systems. It is not sufficient to assign the same RPC ID to a number of processes to link them, but they must also have the same integration points assigned.

After updating a process definition that contains an RPC assignment, the registry will be automatically updated with the integration information.

Helpful reports and transactions:- Use transation POC_UPDATE_REG to update the Registry manually.- Use transaction POC_CHECK_REG: check if the registry in the local system is consistent with the master registry.- Use transaction POC_FED_DATA to view the content of the central registry

144

BRFplus Integration Points:- Customer-defined Process Status additional to System Status- Binding of Task to Activity- Calculation of Classification KPI- Threshold Calculations

How to add a BRFplus Rule in transaction POC_MODEL:- Select entry in the list (if necessary create list entry first!)- Press button ‚Create BRFplus rule‘, then save first before going on. A rule ID should now be visible.- Press butten ‚Edit BRFplus rule‘

Besides using the BRFplus to create return values for Process Observer, you are also able to trigger side effect from BRFplus, for example by calling function modules or triggering workflows.

As an alternative to the BAdIs you find BAdIs.(not available in all SPs)

In releases < SAP_BS_FND 702 you can only use the BAdIs.

146

Thin can for example be filled in BAdI: Enrichment of Process Definition Data

150

The customer includes structures of the process log are also available in the interfaces of the data sources. To make them available for extraction you need to simply add the custom fields to the data source definition, using the standard extension technology of the datasources.

Step by step guide to enhance data sources: http://scn.sap.com/docs/DOC-11632

Alternatively to using the customer includes, you can also create custom table and fill them in BAdI: Enrichment of Task Log Data

151

http://scn.sap.com/docs/DOC-11632

BAdIs for Process Definition (blue)

BAdI: Enrichment of Process Definition Data (POC_MODEL_PROC_DEFINITION)This Business Add-In (BAdI) is used in the Process Observer (CA-EPT-POC) component. You can use this BAdI to enrich process definition data.

BAdIs for BOR Event Processing only (green)

BAdI: Mapping of Business Object Repository Events to Tasks (POC_INSTR_MAP_EVT_TASK)This Business Add-In (BAdI) is used in the Process Observer (CA-EPT-POC) component. You can use this BAdI to extend the mapping of Business Object Repository (BOR) events to tasks.

BAdI: Previous Business Object Determination (POC_INSTR_PRE_BO_DET)This Business Add-In (BAdI) is used in the Process Observer (CA-EPT-POC) component. You can use this BAdI to implement a specific determination of previous business object (BO) information for BOR events instead of using the event payload customizing or relying on the default to use document relationship browser (DRB) to determine the previous BO. For details see also the technical documentation of the BAdI.

BAdI: Map Previous Business Object (POC_INSTR_MAP_PRE_BO)This Business Add-In (BAdI) is used in the Process Observer (CA-EPT-POC) component. You can use this BAdI to map the previous Business Object (BO).

BAdI: Enrichment of Task Event Data (for BOR Events) (POC_MAIN_BA_EVENT)This Business Add-In (BAdI) is used in the Process Observer (CA-EPT-POC) component. You can use this BAdI to enrich task event data for BOR events by using the customer includes provided in the interface structures.

BAdIs for Processing of all Events (red)

BAdI: Enhance/Split Tasks (POC_MAIN_TASK)This Business Add-In (BAdI) is used in the Process Observer (CA-EPT-POC) component. You can use this BAdI to enhance/split tasks.The BAdI is executed before the determination of the process definition or instance take place. [Not available in all SPs.]

BAdI: Enrichment of Task Log Data (POC_MAIN_BA_LOG)You can use this BAdI to enrich process log data before it is written to the process log. You can either write additional data to fields you add to the customer includes provided in the inteface structures for the process log, or you can also trigger the update of own tables from this BAdI.

BAdI: Extend Datasources for BW Extraction (RSU5_SAPI_BADI)This Business Add-In (BAdI) is used in the SAP Business Information Warehouse Extractors (BC-BW) component. Using this BAdI you are able to either fill fields with data, or change the content of the DataSource fields that you added to the extract structure of a DataSource as an append structure.

For enhancing ODP, (BAdI BADI_RODPS_DATASOURCE_EXT), seehttp://help.sap.com/saphelp_nw70ehp3/helpdata/en/8a/4121d239094ffebac228e05771cb82/content.htm

152

http://help.sap.com/saphelp_nw70ehp3/helpdata/en/8a/4121d239094ffebac228e05771cb82/content.htm

During processing of BAdI Enrichment of Log Data (POC_MAIN_BA_LOG) you can further update own tables.

The content of fields in the customer includes is automatically moved to the data sources. Only the meta information of the data sources needs to be updated, if fields are added.Step by step guide to enhance data sources: http://scn.sap.com/docs/DOC-11632

For data source extraction to BW there is further BAdI: Extend Datasources for BW Extraction (RSU5_SAPI_BADI) available for enrichment.

153


In this case: ‚Create‘, ‚Update‘ and ‚Delete Sales Order Item Task‘ are defined as to be depending from ‚Update Sales Order‘ (Header) Task.If now the ‚Update Sales Order‘ Task is not directly assigned to an active ProcessDefinition, the BOR event behind it will still be set to activated for Process Observer, as there are depending tasks that are assigned to an active Process Definition.

154

Note: there is a significant negative performance impact when tracing is turned on, so it should be avoided in production if possible.

Process Observer traces:- Deletion of process log entries (even if trancing is not turned on, for compliance reasons)- Events not matching with definitions- Other errors

There are other further options for analyzing problems:-Report ‚Display unassigned tasks‘ (transaction POC_DISPLAY_BA)-Report ‚Display Task Log‘ (transaction POC_DISPLAY_BA_ORPHANS)See online documentation for further information.

156

Process Instance will be deleted including all depending information.Only “Finished” processes can be deleted.

158

All processes can be deleted. No restriction to ‘Finished’ processes.

159

‚My processes‘ processes in which I executed a step.

‚Monitoring display‘ refers to monitoring in POC_MONITOR, or corresponding webdynpro application, and Enterprise Search.‚Analytics display‘ refers to analytics in ODP. The authrization concept for ODPs can be extended in the ESH modeler (transaction EHS_MODELER).Analytics on top of BI Queries requires an own authorization concept to be set up by the customer.

Access to other transactions is controlled by transaction code or application authrization.

161

Process Observer is delivered with Software Component Business Suite Foundation (SAP_BS_FND).It is currently available for the software component versions SAP_BS_FND 7.01, 7.02 and 7.03.The Business Suite Foundation is part of almost all Business Suite product based on Web AS ABAP.

Business Suite 7 contains: SAP ERP 6.0 EhP 4, SAP CRM 7.0, SAP SCM 7.0, SAP SRM 7.0Business Suite 7i2010 contains: SAP ERP 6.0 EhP 5, SAP CRM 7.0 EhP 1, SAP SCM 7.0 EhP 1, SAP SRM 7.0 EhP 1Business Suite 7i2011 contains: SAP ERP 6.0 EhP 6, SAP CRM 7.0 EhP2, SAP SCM 7.0 EhP 2, SAP SRM 7.0 EhP 2

For details on your products, please consult your System Landscape Directory.

Note: There are different features available with different Support Packages.

165

SAP_BS_FND 701 SP11 restriction: no BRF+ integration. Instead BAdI wil be provided.Webdynpro versions for Process Monitor and Process Viewer are not available in SAP_BS_FND 702 and 731

We recommend to use always the latest support package available for Process Observer.

If you require one of the following features:- External / Direct Event API- Threshold handling- Tracking on BO-Item levelYou should apply at least the following SP levels:

Business Suite 7: SAP_BS_FND 701 SP 11Business Suite 7i2010: SAP_BS_FND 702 SP08 or SP09Business Suite 7i2011: SAP_BS_FND 731 SP02 or SP03

ODPs are only available with Business Suite Foundation 731.

166

We recommend to use the latest BI Content SP available for your SAP BW installation.Depending on the BI Content and SP level you are using, there are different amounts of predefined content delivered for Process Observer.

167

Please carefully look at these notes, at this point in time they are consideredparticularly relevant.There may be additional notes.

168

Process Observer Home Page in SCN Overview page with links to presentations, articles and blogs.http://scn.sap.com/docs/DOC-24983

TechEd 2011 Recordings:Lecture "Big Picture Process Orchestration from an Application Point of

View" (PMC212): a bit more general, but still with focus on Process Observer.

View the recording of PMC212 from TechED Las Vegas.

http://www.sapvirtualevents.com/teched/sessiondetails.aspx?sId=171

172


http://www.sapvirtualevents.com/teched/sessiondetails.aspx?sId=171

Process Observer in SAP Help Portal• Business Function Documentation

http://help.sap.com/erp2005_ehp_06/helpdata/en/3d/ec3aaca2264acf91e2c95d3450881d/frameset.htm

• Application Documentation for Process Observerhttp://help.sap.com/erp2005_ehp_06/helpdata/en/33/14dd25b1964c6b8b44cf5b9d757b81/frameset.htm

• BI Content Documentation

http://help.sap.com/saphelp_nw70ehp2/helpdata/en/c9/3e38a2779b4fb5a6e203301f9d8145/frameset.htm

• BI Content Extensionhttp://help.sap.com/saphelp_nw70ehp2/helpdata/en/6a/f247bf0ce745eab5648a309fbd784e/frameset.htm

174

http://help.sap.com/erp2005_ehp_06/helpdata/en/3d/ec3aaca2264acf91e2c95d345

http://help.sap.com/erp2005_ehp_06/helpdata/en/33/14dd25b1964c6b8b44cf5b9d

http://help.sap.com/saphelp_nw70ehp2/helpdata/en/c

http://help.sap.com/saphelp_nw70ehp2/helpdata/en/6a/f247bf0ce745eab5648a309

© 2012 SAP AG. All rights reserved. 27

No part of this publication may be reproduced or transmitted in any form or for any

purpose without the express permission of SAP AG. The information contained

herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain

proprietary software components of other software vendors.

Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of

Microsoft Corporation.

IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5,

System x, System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries,

zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390

Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6,

POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes,

BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF,

Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere,

Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM

Corporation.

Linux is the registered trademark of Linus Torvalds in the U.S. and other

countries.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or

registered trademarks of Adobe Systems Incorporated in the United States and/or

other countries.

Oracle and Java are registered trademarks of Oracle and/or its affiliates.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and

MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of

W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

© 2012 SAP AG. All rights reserved.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP BusinessObjects

Explorer, StreamWork, and other SAP products and services mentioned herein as

well as their respective logos are trademarks or registered trademarks of SAP AG

in Germany and other countries.

Business Objects and the Business Objects logo, BusinessObjects, Crystal

Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business

Objects products and services mentioned herein as well as their respective logos

are trademarks or registered trademarks of Business Objects Software Ltd.

Business Objects is an

SAP company.

Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL Anywhere, and other

Sybase products and services mentioned herein as well as their respective logos

are trademarks or registered trademarks of Sybase, Inc. Sybase is an SAP

company.

All other product and service names mentioned are the trademarks of their

respective companies. Data contained in this document serves informational

purposes only. National product specifications may vary.

The information in this document is proprietary to SAP. No part of this document

may be reproduced, copied, or transmitted in any form or for any purpose without

the express prior written permission of SAP AG.

process observer in-depth workshop

Documents

process extensions

process definitionsbuilt

process repository

process instance

process model

process business logic

process log data

endtoend process visibility