There are different ways to achieve federation across multiple systems using Process Observer. After recent inquiries from customers I think it may be worth to share one specific approach here. This post will be a bit technical and detail-oriented to help you along with the specific situation around federation described - which may actually be not that specific.
Process Observer supports federation across systems* at design-time by using Process Chains. A Process Chain is an ID that is assigned to multiple processes. All these processes then belong to the same Process Chain. You can also do that for processes in the same system, which we then call local federation, or for processes in different systems as described in this post. It is a prerequisite for this federation across systems that all systems concerned share a common registry. You can find some basics on federation in the Process Observer In-Depths Workshop.
For this article let's assume that we look at two processes, P1 and P2, that belong to one Process Chain*. P1 and P2 are located in different logical systems and Process Observer is active in both systems for P1 and P2 respectively, i.e. the logs are created in each system for each process. The Process Monitor (transaction POC_MONITOR) will show you the process log end-to-end and across systems, incdicating the local and the remote processes*:
The standard scenario assumes that P1 triggers, i.e. starts, the first activity of P2, preferably through some synchronous communication. Technically what happens is that activity A1 of P1 and A2, the start activity of P2, share the same transaction ID. This is something that happens automatically, at least for most types of synchronous communication like RFCs. At runtime, Process Observer is able to find for any process instance of P1 the related process instance of P2 and vice versa - across system boundaries. You can see that in the Process Monitor: It will show the complete Process Chain, not just the local process. As always for federation, you need to set up the integration points between the systems accordingly: Outbound from A1 and inbound to A2. The complete process chain definition looks like this:
Now things get complex if the two related processes actually do not communicate - or at least don't start each other. Maybe the starting point of the process chain is some system that cannot be connected to Process Observer, such as Microsoft Outlook: Mails are send out to different people for them to start the processes P1 and P2. While related on a business level, the processes don't know of each other on a technical level. If you still need to federate P1 and P2 you need to do some extra work. First of all, P1 and P2 must share a common identifier ID1. This identifier should be derived from information that is available in both processes.
Now a little digression to explain how federation works at run time. Starting from an instance of P1, Process Observer will search for Processes of type P2 in the remote system, which start with an activity with the same transaction ID that the outbound activity of P1 has. Understanding that, the way to link the processes from Process Observer's perspective is simple: Make sure one activity in each process has the same transaction ID. The activities must be defined as integration points at design time.
The challenge is how do you set the transaction ID explicitly? If the events are created using the Direct Event API*, you can explicitly set the transaction ID. If you are processing BOR events*, you need to implement method enrich event of BAdI POC_MAIN_BA_EVENT. You can change the transaction ID - or any other data - of all tasks that are generated from BOR events. This has to be done for each process, i.e. on both systems. The ID that you use as transaction ID must be known in both system and it must be unique in each system. So whatever you use, it should not occur later in any process again in that system. The BAdI will allow you to read data, so you can do a complex computation at this point, but please do not do any remote calls here.
Since the integration is always between the outbound integration point and the inbound integration point and the inbound integration point must be the first executed activity of the process, you need to take extra caution if P1 and P2 are not synchronized, i.e. if the outbound and inbound activity can happen in any order. While Process Observer does not consider the time stamps of the outbound and inbound activity - the outbound may happen after the inbound - the Process Chain will only become visible once both the inbound and the outbound activity were executed, and that can lead to confusion - it is not a technical limitation, though. Thus it can be a good idea to link the two processes through the respective start events, this makes sure that the processes are linked and visible immediately when they have started.
All of this is a bit technical, but I hope it helps if you have this specific problem with federation.
* Here are some details that I left out above to make the text a bit more readable, but it may help if you understand them once you try to implement the approach.
- When talking about system, for Process Observer that refers to logical systems. So this may be different physical systems (SIDs) or it may just be different clients in one system, which is something that can be used for testing
- Process Monitor shows local and remote processes differently, depending on release and support packages; the latest releases actually show activities of remote processes in a different color, generally a darker blue; there is always a column showing the source system, though
- The approach described above will also work if more than two systems or processes are concerened; the example above assumes two processes, this is for simplicity only
- The API mentioned to create events is POC_RAISE_EVENT, for more details see the blog entry on the Direct Event API
- When talking about BOR events here, this includes the class-based events, i.e. events raised against ABAP objects implementing IF_WORKFLOW
- SAP Managed Tags:
