cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Process Observer Discussion

JChristophNolte
Product and Topic Expert
Product and Topic Expert
0 Likes
10,977

This thread is dedicated to questions and discussions around the Process Observer component that is part of Business Suite.

Process Observer is used in different scenarios, including and prominently with Operational Process Intelligence.

For details on what Process observer is see here.

View Entire Topic
Former Member
0 Likes

Hi Christoph,

I have a problem with Process Observer. It does not recognize the relationship between a sales order and a related delivery although the relationship between these objects is present in the report POC_DRB_BOR_RELSHIP. I can see the delivery in POC_TASK_ORPHAN. There are no problems mentioned in POC_MODEL_CHECK. Have you got an idea where could be the problem?

SAP ECC 6.0 EHP5

SAP_BS_FND 7.02  SP09              

Thanks,
Jens

JChristophNolte
Product and Topic Expert
Product and Topic Expert
0 Likes

Hi Jens,

this should really, really work: It's pretty much the most used demo case... so this does work. If we are talking about the SD sales order in ERP (VA01 etc.) and the related oubound delivery (BOR object LIKP, transaction VL01N)...

Since you can see the task in the orphan report, the event was raised and mapped to the correct task. And it links okay to the sales order if POC_DRB_BOR_RELSHIP shows it.

Potential problems I can think of:

  • You are somehow creating sales order and delivery at the same point in time, so when the data is processed it's not really on the database... (so you are not manually using VA01 & VL01N to create the data) - generally that should work anyway, but that could cause issues... maybe.
  • Check the outbound delivery activity and its associated task - are you sure you're seeing the task you have in the definition as an orphan? Or are you using a "similar" task?
  • Do you have some BAdI active? You can overrule the default predecessor determination using DRB... maybe you have done so (but obviously not very well - maybe you have done something for other objects and that's kicking in now with the delivery doing strange stuff).
  • Something else I can't think of... and I'd need more information.

It's probably a good idea to raise an OSS, we're happy to help.

Best regards,

Christoph

Former Member
0 Likes

Hi Christoph,

even if a create the delivery hours or days later, it doesn`t work.

Yes, I am sure; if I change the process definition and mark the delivery as a start activity, Process Observer creates a new process instance after using transaction VL01N.

I have no idea about BAdl; never used it before. No one except me uses Process Observer on the System I am working.

Is it possible to use „Map Previous BOR Objects from BOR Payload“ to overrule DRB in this case?

If is it possible, may you tell me how to fill this view? There are no sample entries in my system.

Best regards,

Jens

JChristophNolte
Product and Topic Expert
Product and Topic Expert
0 Likes

Hi Jens,


something is wrong is going on. This really should work. - The idea to mark the outbound delivery as a start object is quite good, but it really supports my statement that it should really work.

The view to map previous BOR object from the BOR payload (it's POC_V_MAPPREVBOR.) won't help here, I think. You can find more on that in the Process Observer In-Depth Workshop on page 57. In this case - besides the fact that DRB should really work - the event LIKP-CREATED (thrown when the outbound delivery is created in transaction VL01N) has nothing (helpful) in its BOR container. When you look at the parameters of event "OutboundDelivery.created" in the Business Object Builder (SWO1) for object LIKP, you see: nothing. This event has nothing in the its payload, so there is nothing to map (well, maybe there is something in the container - the information here is not always complete - but it is not helpful in this case).

Going back to what really should work: DRB. You have stated that POC_DRB_BOR_RELSHIP does show the sales order. Please really check that!

One more thing that you should check is table POC_D_PRE_BA. In POC_MONITOR check the process ID (you need to add that to the list of visible columns in the ALV on the search page of POC_MONITOR) of the process that has the outbound delivery created when you made the creation of the outbound delivery a start activity. In SE16 for table POC_D_PRE_BA check if for that process_id you there is an entry. The entry of the predecessor should be there, even if the predecessor does not exist on the database (this is used for local federation). - Alternatively you can use the task ID of the outbound delivery task using POC_DISPLAY_BA. I am not sure what to expect, but it would be helpful to know if there is an entry.

Other than that... I'm pretty lost. My next step would be to put a break-point in CL_POC_BOR_EVENT=>GET_PREVIOUS_BOS_DRB where CALL FUNCTION 'DRB_NEIGHBOURS_GET' is called and see if lt_previous_bor_objects is filled as expected. I suspect that this method is never called because of something strange (BAdI-implementation) is going on.

If this is all fine, I would check in BOR_EVENT_HANDLER at the end, right when CALL METHOD lo_poc_ba_observer->raise_event is executed and inspect lt_ba-PRE_BO_DATA if that is filled as expected.

If this is all well, then things get a bit more complicated.

To execute the break-points, you will need to un-schedule the report in SM37 (POCR_MAIN_QUEUE) and execute rswfevtpoqueue in dialog. This should be done only in a test enviroment, since it may lead to issues with direct events that should be processed in proper order - events may thus be ignored or added to the log in the wrong order.

I think we're at a point where you should raise an OSS - or at least talk more directly since finding this issue may become a tedious and lengthy issue if we have talk solve the problem by you checking the data etc.


Best regards,

Christoph