reprocess event message

[Former Member]

Hi all experts,

Is there a way to reprocess already processed event message in EM? Scenario is, I receive an event-->rule set process-->in one of the ruleset activity i reset the event status using EE_RESET due to some update failure in external system.

Now I may not get the event message again from external party, but I need to reprocess this message again after sometime as i know that update failure won't occur in external system. This will set my EE status to green.

Thanks in advance,

Anu

[Former Member · Accepted solution]

Hi Anu,

Right now, we have only option to reprocess through SAPTRX/EH_LIST -> Header-> Reprocess Event Messages to reprocess same event message.  The reason being, we should not manipulate reported event and post it as some company uses for audit purposes.

The ideal option would be post a new event instead of updating existing event as this will also enable to you track down how many events are not posted due to errors.

Regards

GGOPII

[Former Member · Accepted solution]

Thanks Vishnu and Gopi,

@Gopi: Reprocess through EH_LIST will reprocess all reported events right? I dont want that to happen. Post a new event also would be a problem as it require manual intervension and not possible in high volume scenario. In my case only few events will get reset due to application system(some kind of update failure - this can be app system down or app system not yet ready to accept this event).

I have to go with custom program i guess, any pointers about how would i know such events(which is reset by rule activity?), do i introduce some custom flag on event header table?

Thanks, Anu

[former_member190756 · Accepted solution]

Hi Anu,

you could try to delete the entry for the processed message in table /SAPTRX/EH_EVMSG. This is the mapping from the EH to the Event Message.

If you afterwards run any change on the EH e.g. calling BAPI /SAPTRX/BAPI_EH_POST it should pick the message again.

I never tried this but for your exceptional case it could work.

Indeed better would be to write a program and send the message again as already suggested in other posts.

Best regards,

Steffen

[Former Member · Accepted solution]

Hi Anu,

To resolve this issue, then follow below steps:

1. Create a  custom report program

2. Create a selection screen according to appending table for example in your case  /SAPTRX/EH_STAT

3. Required append tables for example  /SAPTRX/EH_STAT but if you need other table then include following tables /SAPTRX/EH_HDR, /SAPTRX/EH_STHST, /SAPTRX/EH_CNTRL, /SAPTRX/EH_EVMSG, /SAPTRX/EH_EVMSG  etc.

4. In the program, you have to write perform codes.

a) Select using EH_GUID from /SAPTRX/EH_STAT table

b) Update Event Handler status and also you need to call method  /SAPTRX/CL_EH_DET_INTF_CNTRL=>SET_STATUS_ATTRIBUTES in the perform program to append new status into table.

This is little tedious work but can be achievable.  Work with your ABAPer and give these details, they will take care rest of the code.

Regards

GGOPII

[former_member186607 · Accepted solution]

Hi Anu,

some general remarks from my side:

If I understand your scenario correctly, updates in application system(s) are triggered out of the rule set processing in SAP EM. Normally these kinds of updates are either triggered

• asynchronously -> status of event message in EM will be 'Reported' no matter if the update in application system was successful or not and in this case the usually the application system or some middleware  take care that the update is executed successfully in the application system. Example for this is qRFC calls between SAP systems.
• synchronously -> result of the update in application system can be evaluated in the rule set, since it is done synchronously. If not successful, you could react somehow in the ruleset, e.g. stop the processing of the event message. By this the status of the expected event will stay as it is (so will not be set to 'Reported').

As far as I understand your case is a bit different, right? It seems that the update in application system has to be retriggered by EM rule set in case of failure. Is there no mechanism in place that takes care that these updates can be retriggered without EM in case of failure (like possible with qRFC)? Or would this be possible, but the requirement is that EE status in EM gives visibility on the update in application system as well? If this is the case, I would suggest to do the update synchronously and directly react on the result in the rule set processing. In case of success the normal rule processing can be finished and everything is fine. In case of error you can quit the processing and EE status will not change. You then need a custom rule activity that stores these event messages in a custom table. Then it would be an easy task to write a custom report that sends a new event message based on the data of the event message  for which the processing has been quit. This report then should be executed periodically.

Best regards, Daniel

[Former Member · Accepted solution]

Hi Daniel, Gopi, Steffen and Vishnu,

Thanks a ton for your valuable inputs and guidance.

@Steffen, @Gopi: change on EH will reprocess all reported events right? this may cause lot of trouble. the doubt for me is, on what basis i would select those events for repost? How do i know this event is processed once but not"successfull" ?

@Daniel: You are right, I have to call app system update synchronously to capture failures.

to answer your question,

1.  Is there no mechanism in place that takes care that these updates can be retriggered without EM in case of failure (like possible with qRFC)?

     Here one situtation is system down where qRFC or tRFC will help. But in case no communication failure, but app system is not ready to accept this event due to other status updates(e.g carrier send evt READY, but my warehouse tasks is not yet ready for example). We woule like one central system to capture all failures and retrigger instead of app system reprocess its own updates.

2. the requirement is that EE status in EM gives visibility on the update in application system as well?

Exactly, that is what we want.

3. You then need a custom rule activity that stores these event messages in a custom table

     Is there any status on event header in standard so that I can avoid custom table?

Thanks again for all for your support.

Regards,

Anu R

[former_member190756 · Accepted solution]

Hi Anu,

a standard mechanism is not available and as you need:

"2. the requirement is that EE status in EM gives visibility on the update in application system as well?"

you also have to post the event message again to EM to reflect the right status on the Event Handler.

So the easiest way is as Daniel has described. Stop Processing in case update to external system fails and create a custom report that resends the Message again. With that all your Requirements are fullfilled.

Is there any status on event header in standard so that I can avoid custom table?

You could introduce your own status. Its freely definable and select then these EH in your reports. But a small custom table i think would be much easier and you avoid to select the EHs.

Best regards,

Steffen

[former_member186607 · Accepted solution]

Hi,

if you use standard rule activity QUIT_EVM_PROCESSING the corresponding entry in table /SAPTRX/EH_EVMSG gets NOT_RELEVANT = 'X' (if you use the activity without activity parameter 'Not Storing'). So it would be possible identify all the event messages for which processing got stopped by QUIT_EVM_PROCESSING. But you would have to introduce some additional selection criteria, because these entries will not be deleted. So you have to take care that only the new entries would be selected by a custom report that sends new event message with same content again (and not the ones that already have been handled by the report before). Maybe you could use PROC_DATE for this.

Best regards, Daniel

[Former Member · Accepted solution]

Hey Gopi,

Anu is talking about EE status ( Green/Red/Yellow ) primarily and re-posting the message again. How will selecting the record from /SAPTRX/EH_STAT will help Anu?

EH_STAT and EH_CNTRL are impacted by re-processing though but selections based on these tables will not help.

Maybe I am missing something here between the conversations.

Thanks,

Vishnu

[Former Member · Accepted solution]

Hi Anu,

I like the Daniel's approach of quitting rather than resetting your EE.

If you are implementing Daniel's approach, which I think will help your case, do the following:

1) Try to add some indicators like sender codes ( SDNCOD ) or data codes on the original message. This can be done on external system or through per-processing. No worries if you can't as well.

2) Add quit activity as Daniel suggested. Your condition should include the codes from step 1.

Now you message is quit by ruleset and not processed.

Use the following program to reprocess your message. You need to do 2 things in the program which I didn't add:

a) Add a select on /SAPTRX/EH_EVMSG ( uncomment it from my code) and parameters to make sure you are picking up the event for processing which you want.

b) Add or modify your sender codes in the program like ls_evm_data-header-SNDCOD = "<your value>". The reason for this is to by pass step 2 so that you are not quitting again.

Hope this helps.

****************************************************************************************************************

****************** Add Processing Date and any other selection criteria ***************
PARAMETERS: p_evguid TYPE /saptrx/ev_guid,
             p_int_ev TYPE /saptrx/event_code,
             p_evtdat TYPE /saptrx/ev_evtdat,
             p_test   TYPE char1.

START-OF-SELECTION.

* Get you event for processing
   SELECT SINGLE evt_guid FROM /saptrx/evm_hdr INTO  ls_evm_guids
          WHERE evt_guid EQ p_evguid
           AND  int_ev_cod EQ p_int_ev
           AND  evtdat EQ p_evtdat.


************** Here uncomment the following logic to   *****
************** cross check this event against EH_EVMSG*****
************** If event is in EH_EVMSG, it means posted then do not continue****

*  CLEAR lv_msgguid.
*  SELECT SINGLE msg_guid FROM /saptrx/eh_evmsg INTO lv_msgguid
*    WHERE msg_guid = ls_evm_guids-msg_guid.
*  IF lv_msgguid IS INITIAL. " this will tell that your message is not posted.

     APPEND ls_evm_guids TO lt_evm_guids.
*--------------------------------------------------------------------
* -> read event message data
*--------------------------------------------------------------------
     CALL METHOD /saptrx/cl_evm_display_view=>get_evm_data_and_text
       EXPORTING
         it_evm_guids     = lt_evm_guids
         is_request_flags = ls_req_flags
       IMPORTING
         es_evm_data      = ls_evm_data
         "et_eh_evmsg      = lt_eh_evmsg
         "et_eh_evmad      = lt_eh_evmad
       EXCEPTIONS
         OTHERS           = 0.

     CHECK ls_evm_data IS NOT INITIAL.
**** Modify ls_evm_data to add additional data which will help bypass the quit processing.
     CALL FUNCTION '/SAPTRX/PROCESS_MESSAGES_02'
       EXPORTING
         is_evm_tables = ls_evm_data
         i_simulate    = p_test
*       IV_EH_GENERATION_MODE           =
*       IV_EH_GENERATION_FUNCTION       =
* CHANGING
*       ET_RETURN     =
       .
*  ENDIF. " Check EH_EVMSG table

[Former Member · Accepted solution]

Hi Vishnu,

Yes we can reset the icon if we want it.  It purely how we defined and write a code based on our requirement.

Regards

GGOPII

[Former Member · Accepted solution]

Hi Anu,

1. Is there no mechanism in place that takes care that these updates can be retriggered without EM in case of failure (like possible with qRFC)?

We have recently gone a live like staging table (buffering what we have in SAP EM) concept where we collect all day events and post events in the night through custom program. You may go with this approach:

a) If any of events failed then will reside the staging table and trigger email to support team.  This way we don't lose data and will be addressed failed events like any preceding event not posted, data incorrect, format issue, sender code issue etc then it will reside in staging table.

2. the requirement is that EE status in EM gives visibility on the update in application system as well?

You can freely define your own custom status based on client requirement as suggested by Steffen.  However, if you want later edit only status then good option would go with custom report to edit directly with reporting the events.'

3.  You then need a custom rule activity that stores these event messages in a custom table.

You can define your customer rule activity to use existing SAP EM standard tables.  There could be some reasons customer project gone with custom table solution as I saw few projects they had gone through storing event message data in custom tables as they couldn't fit their custom solutions.

Regards

GGOPII

[Former Member · Accepted solution]

Hey Gopi,

The steps you proposed to resolve Anu's issue are misleading. Rest of the forum who might have  similar issue of reprocessing events/resetting EE Status might look at the steps and will be misled as it's one of the helpful answer and you are one of the top contributors to this group.

Your solution is for updating EH status using custom program. Maybe you can add clarifications to it.

[Former Member · Accepted solution]

Gopi,

Expected event status and Event handler Status are two completely 2 different things.

Thanks,

Deb

[Former Member · Accepted solution]

Yes Vishnu you are right.

Regards

GGOPII

[Former Member · Accepted solution]

Thanks all the experts here.

To conclude,

1. When the event comes in EM, trigger necessary update to app system synchronously. Asynchronous process will create more complexity as we cannot catch the return code from app system OR if async, we have to again report the success/failure from app system to EM which is tedious and makes inconsistency between systems for shot perios of time.

2. Quit the evnt processing if app system say 'failure'. Log the event into a custom table

3. create a report to repost the event.

Thanks again friends  and I am closing this thread as anwsered.

Regards,

Anu R

[Former Member]

Hi Anu,

Looks like your in desperate need of reprocessing program without creating new event or reprocessing all the events.

In that case, you need to develop a custom program similar to method "process_msgs".

Class: /SAPTRX/CL_EH_EVENT_MSG_MODEL

Method: PROCESS_MSGS

You cannot directly call this method as it's protected. This method will not check if your message was processed or not and will try to process the event again. I am not sure of the impact if you reprocess the event though.

Also, unless you take care of your EE_RESET activity or it's condition, it will not matter how many times you re-process it. It will reset EE again.

Also, you need to be aware of the impact to existing statuses, changes to parameter values or any other changes to EH due to reprocessing a single event which may or may not be your latest event on EH.

Let me know how it goes.

Thanks,

Vishnu

[Former Member]

Hi Anu,

There is no standard program available for re-processing. All we have for reprocessing is on EH list -> EH Details screen. There is a button to reprocess. This will reprocess all your events.

In your case, it might not work as you have a EE_RESET activity. If conditions match, this will reset your expected again after posting.

So, you have to remove your RESET activity and for posting:

1) Use EH list to re-process messages

2) Manually post the event again.

You have to be careful here as significant changes to EH will also reprocesses all the event messages.

Thanks,

Vishnu

[Former Member]

Thanks a lot Vishnu,

I dont want to reprocess all event message for EH

Here in this case, message is processed, but in ruleset processing i reset the status to 'un' reported or expected again.

Anyway to reprocess only such event messages(processed , but status reset by ee_reset)?

[Former Member]

Hi Anu,

I haven't seen any program or standard way to re-process any particular event unless it's a LOCKED event.

In your case, your options are limited

1) Create a custom program to read back and re-post the event which you want to re-process.

2) If you have EM webui, manually post this event again.

In both the options, you are creating one more event ( one more entry in /SAPTRX/EVM_HDR and related tables ) but not exactly re-processing the old event. Also, unless you take care of your EE_RESET condition, it keeps resetting your Expected Event.

Let me know if you need additional inputs here.

Thanks,

Vishnu