EM Handler - Control Parameters and Tracking IDs (MISHAP)

[Former Member]

2 Part Question:

1. Has anyone ever seen this happen before?? This is a FU handler (Notice the many PO and TRQ references...):

Any ideas what may have happened? Furthermore, how do I clean it up but again bigger question is what went wrong???

2. When I update the FU within SAP TM the Control Parameter and Tracking ID extraction functions are called and the correct data is pulled. Why isn't the handler getting updated appropriately during the extraction? (Standard Extraction Functions) I would expect that if TM extractor pulls in different from what is currently in the handler then the handler would be updated accordingly.

[Former Member]

Jacob ,

Do you mean to say that TM extractors are not sending ODT20_PO_ID and it is getting generated in EM ?  Please put a debugger in the TM where it calls BAPI to post EH in EM . Please check and confirm if ODT20_PO_ID is not being sent from TM to be sure . If this is the case , then check parameter mapping in EM side .

Could you please send screenshot of standard relevance function which you are using and explain what it checks basically .

[Former Member]

Rajesh,

Please refer to the following link for my question regarding EM AOT relevance functions.

http://scn.sap.com/thread/3870826

[Former Member]

Jacob ,

As I explained deletion (Action=D) will happen when item will be deleted . When there is change before and after then it comes with (Action code = U) .

I have identified one thing that incremental of index is not a issue since value of ODT20_PO_ID are different in each line . So index will be increment for sure .

Please check EH relevance function and try to find out why different PO items are considered in one freight unit ?

[Former Member]

Rajesh,

I understand the (Action=D) now. So the extraction function is only going to remove from the EM control parameters IF and ONLY IF the BEFORE had an item for example and the CURRENT does not have an item.

My question is though, say the event handler for some reason shows multiple ODT20_PO_ID references shouldn't there be some check somewhere that says the data extracted from TM doesn't match what is in the EM header details? I'm really not sure how these EM handlers got all of this extra data....

EH Relevance Function:

What a great topic, we are still using standard, which really does not additionally checks. I've been informed by SAP that I need to create custom relevance functions but I'm not certain how to do this or what should be checked and I've had trouble finding documentation on the subject.

[Former Member]

I have captured some screenshots of the standard Control Parameter extraction function. As you can see at the end of the function there are 27 parameters:

Notice the what the EM handler shows???

Question 1: Where/when do the ODT20_PO_ID parameters get picked up? I don't see them in the standard control parameter results.

Question 2: Notice there are still many TRQ_IDs along with those PO_IDs and if I were to scrole down there would be many DELIV_IDs as well?

[Former Member]

Hi Jacob,

I do not see any issue in any of your screen shots ( config and extraction ). Do you have any custom resend activity? Somewhere in your design, indexes are being added even though you are sending index 1 from extractor for your TRQ and Delivery. Other question is how are you adding your ZZ* params in your standard extractors?

If you cannot find a spot where these params are being added, then open an OSS.

Thanks,

Vishnu

[Former Member]

Forgot to attach the screenshot I guess (Feb 26, 2016 8:24 AM):

[Former Member]

Hi Jacob,

I strongly feel it's your method PARAMETER_CHANGE_NEW which is doing this. Somehow it might be incrementing the parameters and it will increment if it doesn't find any value index pair to start with.

But it doesn't explain why thousands of values are being added. How many events do you have on this particular EH?

Thanks,

Vishnu

[Former Member]

Cheeti,

The ZZ* params are being added through Extract Data configuration as opposed to functions since there are only a few.

What should I look for within the ZRESEND_MULTIPLE function?

Additionally, as I mentioned in my 8:24 AM post do you happen to know how the ODT20_PO_ID gets added as a parameter? I don't see it within the standard extraction function??

[Former Member]

Do you have any update activity or pre-processing functions?

[Former Member]

Cheeti,

As for the PARAMETER_CHANGE_NEW:

1. The EH has 7 reported events.

2. Are you suggesting that my PARAMETER_CHANGE_NEW rule isn't setup correctly?

[Former Member]

Cheeti,

We do not use any custom update activities. We do have a pre-processing function however which does the following (do you see anything really wrong in here?):

But this is only called when events are reported correct? I've also got many examples within this quality client of FUs that have not yet been planned and so they have reported events....

[Former Member]

Hi Jacob,

Your control rule setup looks ok but I would definitely debug it and see. As for your PO parameter, looks like it's not coming from extractor. For all your events for this EH, pickup all EVM_GUID from /SAPTRX/EVM_HDR and see all the records in /SAPTRX/EVM_PAR. In EVM_PAR table, can you see PO parameters? If yes, provide screen shot.

Thanks,

Vishnu

[Former Member]

Didn't see any obvious error in your pre-processing. Can you please provide /SAPTRX/EVM_PAR entries? Especially for PO, TRQ and Delivery.

Thanks,

Vishnu

[Former Member]

Cheeti,

I just checked all of the event messages within that handler and they all only have the Z_TOR_TYPE control parameter as part of the message.

Looking deeper into the standard control parameter extractor (/scmtms/extr_cparams_tor) I do see where <fs_purch_id>, <fs_sto_id>, <fs_sales_id> are mentioned in the function but I'm not yet sure why they control parameter fields aren't getting updated to match the data extracted currently within TM when I make a change to the document.... hmm

Looks like the PO_ID should get added on line 973. But as for the removal of the existing parameters looks like it only happens if ITEMs are removed? (line 1020).

My hope was that these extraction functions should keep TM and EM in sync with the appropriate parameters.

I'm seeing the same issue with FB handlers that inappropriately show ASSIGNED_FU control parameters when they aren't assigned within TM. (lines 371 - 384) should address this but again doesn't seem to be executing.

[Former Member]

Hi Jacob,

What is your TM version? I guess you are using extractor from ODT30_TO version of TOR. Do you have ODT40_TO version of AO Type in your system? If yes, replace your control param extractor with this new extractor. Maybe that will solve your issue.

New extractor FM is /SCMTMS/EXTR_CPARAMS_TOR40

Thanks,

Vishnu

[Former Member]

Unfortunately we are currently a bit behind on TM version. ODT20 is the version I have available at this time.

I think I'm beginning to understand that these Parameter extraction functions are just going to communicate the changes to Control Parameters based on the information within TM. I guess my hope was that if the data within EM handler was way off base it would be overwritten with what is extracted from TM. That hope is looking like a dream.

I really am still confused at what the root cause may have been that added so many wrong parameters to the handlers. And now since TM is not aware of these additions to the Event handlers, it won't signal the change to update them appropriately. Again, this is most concerning for us regarding the 'ASSIGNED_FU' field on the FB documents because we have processes that rely on those (ASSIGNED_FU) parameters matching exactly what is within TM at all times.

[Former Member]

Can you try creating an brand new EH without any events if your process allows and see the parameters.

If it looks OK, in the second step change TRQ assignments and now see how the parameters look in EH ( without any events in this step too if possible ).

If you see any unwanted parameters, then most likely your extractor is the culprit and re-write the extractor by adding appropriate action = 'D'.

Meanwhile it's better to open OSS.

Additionally, I can paste the OD40 parameter extractor code and you can copy it and test it.

Not sure if moderators allow me to paste the SAP code here but if you need it I will paste it anyway.

Let me know.

Thanks,

Vishnu

[Former Member]

Jacob,

I agree with Vishnu. Did you test by removing 'X' from 'Src. Name/Value' in activity with method PARAMETER_CHANGE_NEW?

Best regards,

Prajakta

[Former Member]

Hi Jacob,

The best way would be debug and find out the rootcause instead of assuming several functions and data where it is an issue.

It may be a custom function or backward compatibility or bug in the code which is causing the issue.

It will be a little bid tedious job to debug to find out a rootcause but it would be an ideal way.

Regards

GGOPII

[Former Member]

Gopi,

Thanks for the feedback. One of the challenges I'm face with is that I don't currently have steps to reproduce. To my knowledge there is nothing wrong with new TM documents and EM handlers. This makes it even more of challenge to determine what could have went wrong and also what is the best way to clean up hundreds if not thousands of handlers.

[former_member186607]

Hi all,

I just wanted to give a little wrap-up on how the issues described in this thread have been solved.

• It may happen in scenarios in which DTRs are created out of OTRs that wrong TRQ_IDs get extracted, which can lead to wrong control parameters (ODT20_TRQ_ID) and tracking IDs (tracking code set TRQ). This issue is solved by SAP note 2306200 .
• The issue with the duplicated control parameter entries for referenced document IDs like purchase order ID or sales order ID is solved by SAP note 2296786 .

Best regards, Daniel

[Former Member]

Jacob ,

Action = D will not help cause that gets triggered when you delete a item in FO . Did you check how parameter index is getting generated . What is the reason of generating so many incremental index ?

[Former Member]

Rajesh,

Action = 'D' is not for only deletions. When something in before and after structures ( old vs new ) doesn't match or due any unassignments, Action = 'D' will remove the unwanted parameters or tacking ids.

Jacob,

Apart from checking how indexes are built in extraction, do you know if you are adding any parameters during event posting?

Thanks,

Vishnu

[Former Member]

Vishnu,

During event posting I do add parameters if they exist within the event message:

Furthermore, I move a parameter from Control to Info with the following in the FU rule set:

Do you notice any glaring issues?

[Former Member]

Hi Jacob ,

It is adding so many parameter cause system is picking up different Index in control parameter extractor . Debug and identify the code how several index are getting generated .

Regards,

[former_member186607]

Hi Jacob,

can you check if the following notes are implemented in your system (or already available because of your release/SP level):

2084540

2109222

2016433

However, these notes will fix some known issues in the standard extractors and I assume that you are not using the standard ones. But you should check if the same correction has to be applied to your custom logic.

But as Rajesh already suggested. You should check your logic regarding the parameter indexes that are extracted. The index numbers look like they are counting up and up.

Best regards, Daniel

[Former Member]

Daniel,

Some of those notes were not applied but that have been now. I went back in and I tried to make a modification on a TM document which triggered the standard Control Parameter extraction function and still the handler is not matching what is being extracted from TM.

I've informed our developer to look into the ACTION = 'D' but I have not heard anything back at this time.

I have additionally opened an incident (132934) so that access can be made into the trouble client.

[Former Member]

HI Jacob,

Are you using standard extractors or custom extractors? Somehow your control and tracking id extractors are not deleting the old/irrelevant entries and only inserting new entries. Can you debug and see if ACTION = 'D' is happening in these extractors?

I am not sure there is any program/utility which you can use to clean them out. Unfortunately you need to write a custom program to take carer of these.

Thanks,

Vishnu

[Former Member]

Cheeti,

I am using standard control parameter extractors and a custom (standard copy) tracking ID extractor. The tracking ID extractor is custom only in that it adds a few additional tracking codesets otherwise it is standard.

I'll speak with the development team and ensure they debug and look for the Action='D'. Why would the Action='D' not happen for the standard tracking ID extractor. hmm...

Any ideas to how the handlers could have ended up like this?

Assuming the extractors were working appropriately what would the custom program need to do to clean them up? Make a change to each TM document? haha not sure how I'll confirm that all were fixed.. Any ideas?

[Former Member]

Hi Jacob,

When this issue is started? Is this started recently upon changing any customization/enhancements in SAP EM.

1. Is this happening for one event type or for all event types against event handler type?

2. Application system uses event type together with tracking id to assign to event handlers.  When the data send it from SAP EM, it refers same event handler for multiple tracking id's and posting his control parameters as well.

3. Go to Event Handlers -> Define Activities for Updating Event Handlers and check any custom function and update which you send data causing the issue.

Clean up:  I don't think we have a custom tool to clean up control parameters and tracking ids.  However you can go to each and every handler delete but it is tedious job to perform.

Regards

GGOPII

[Former Member]

This has happened for multiple event handler types. I've checked the 'Event Handler -> Define Activities...' and we have no custom activities.

This is very strange...

[Former Member]

Hi Jacob,

Can you check this discussion?

Delete parameter with index unknow | SCN

Regards

GGOPII