Process Observer – Old dogs and new tricks, part deux
In my first blog of this series, I laid out the resources I had found for learning about this new (to me, anyway) tool, and activated it. You can read it here.
In this blog, I try to get down to brass tacks, so to speak. I will use mainly the IMG to step thru turning on a process, although I also refer back to my trusty workshop as well as the main Process Observer (POB) page.
Via transaction SPRO, navigate to: Processes and Tools for Enterprise Applications > Process Orchestration for Built-In Processes
1) Maintain Objects in Façade Layer
The first time thru here, I admit to being a little lost. BO Type 001 = Purchase Order? In whose world? In mine, it’s BUS2201. I’ve later understood that these are (as the name suggests - Façade ) essentially SOA objects, so it’s not necessary that there is a ‘direct link’ to good old BUS2201 here. Since I didn’t really understand this (these BO types and Task Types are alien) I went with creating my own. The again, the TaskTypeIDs were also a puzzle, so I just created my own.
- Do it better– don’t bother creating your own BO Type and Task first off. Use a BO Type that you can relate to. Remember a Business Object Type (BO Type) is in the Facade Layer, and a BOR Type is from the Business Object Repository.
2) Activate Business Object Log– Easy! I turned on Standard Logging with my custom BO Type! This step links the activation with the BO Type (not the BOR Type).
3) Maintain Business Area– You will probably use this as you go forward – but first off, you can give this a pass. This is not a ‘Business Area’ as in GSBER, but a filter to be used in the BADIs. Still, I wanted to tick all the boxes in the IMG, so I created a Business Area anyhow.
4) Maintain Business Object Repository Instrumentation
Well, this is just what I wanted! Someplace where things I already know about can be linked to the POB BO Types! Onward!!!
This is where the rubber meets the road – the linkage between the BO Type and the familiar old BOR type BUS2201. You’ll note that this is why I said you should run with the predefined/delivered BO Type – it is already linked to BUS2201, so my entries were superfluous.
But I have a minor whinge when I read the help on this topic:
Maintain Business Object Repository Instrumentation
Use
In this Customizing activity, you create an infrastructure whereby events specific to the Business Object Repository (BOR) are captured, using logging, by process orchestration.
Requirements
BOR events are available in the system.
You have defined reusable tasks and business object types in the facade layer.
You have enabled the switched package BS_POC_SFWS_01.
Activities
You must carry out the following activites:
Map BOR events to tasks in the view cluster POC_VC_BOR.
Map business object types to BOR objects in the view cluster POC_VC_BOR.
Set the report RSWFEVTPOQUEUE as a background-running job.
My whinge here is that telling people to maintain a view cluster isn't very friendly.
* Do it better– Don’t try to find view clusters to maintain. The transaction POC_BOR will contain all the Business Object Repository maintenance.
And no, I’ll say it again (I said it in my previous blog) you do not need to be a workflow developer to turn on POB.
5) Map Previous Objects from Business Object Repository Payload – After hemming and hawing on this one, I decided this would be necessary in case of a process definition that spanned BO types.
6) Schedule Business Object Repository Event Processing. No prob.
7) Check Process Monitoring Events for BOR
- At this point, I have already learned some lessons. Originally, I thought I should create my own BO Type (not to be confused with BOR objects) – as it turns out, I was wrong. I got some excellent counseling from the POB Team ( Christoph Nolte and Peter McNulty ) and they set me straight.
- Everything is not all about the BOR. Yes, it’s like a nice comfy old robe, but the POB functionality was built to be inclusive of BOR objects, not exclusive. Don’t let it throw you.
- You will notice that these customizing entries were not really ‘technical’ – there is no coding, no workflowing, no ‘logic’ behind them. This is why it’s clear that you need to have your business analysts engaged. Since I am working on a prototype, I can just forge ahead and make these things up. But in a real POB implementation, I am going to have the business people in on this. There is more stuff later on, as I define my Process Definition, where they could really be helpful.
This seems like a good breaking point. My next blog will focus on the actual process definition. Meanwhile, I'd like to ask you - are you thinking of implementing POB? You do know it's a 'gateway' to Operation Process Intelligence(Powered by HANA) right? If you have already implemented POB, what benefits has your organization seen