DBSQL_DUPLICATE_KEY_ERROR - ST22 Dump

[Former Member]

Scenario:

1. ZRESEND_MULTIPLE is used within our FO/FB EM handler to resend ALL events to the assigned FU handlers.

2. We didn't appear to have any issues until we configured an Event Data Type for reporting an event on the FO/FB handler upon FO/FB creation (ZTREQ_CREATED event).

3. This 'ZTREQ_CREATED' event reports fine on the FO/FB handler and then is properly sent to all of the assigned FUs. However now when we execute an event via IDOC on the FO/FB we are getting the dump DBSQL_DUPLICATE_KEY_ERROR (CX_SY_OPEN_SQL_DB) within program /SAPTRX/SAPLEH_FUNCS.

4. The dump appears to occur after the event is sent to the FU handler (AOT) during /saptrx/eh_update of the l_task_ins table???

Any thoughts?

[Former Member · Accepted solution]

I went ahead and removed all 'Log Task' check boxes from the Event Handler rule set activities and multi-task activities. Now there is no dump!! YAY!

What is this "Log Task" for? I thought it would be required to see the task within the EH logs but I see the EH log for a given handler still shows the activities performed. So what is the purpose of checking this box?

Also not sure why all of a sudden these dumps appeared; these tasks have been checked for quite some time.

[Former Member · Accepted solution]

The log checkboxes will help in capturing the rule activity which was triggered for a particular EH. It will tell us if it a rule was processed or not for which event.

It's not required and should be unchecked for all the rules/activities from performance stand point.

You can keep it checked initially for kind of debugging but remove before afterwards.

Not sure why this was dumping in your case.

Good thing it worked.

Just a note: Uncheck all the logs before going live:)

1) EH Log

2) EM Log

3) Task Log

4) Application Log

Let me know if you need path's and I can send it to you.

Thanks,

Vishnu

[Former Member · Accepted solution]

Hi Jacob,

When you enable Log task then it will update in table /SAPTRX/EH_TASK.

/SAPTRX/EH_TASK table is not only update from Ruleset when you enable log task.

Go to these config areas and disable if you have already enabled Log task.

1. Multitask EH Update Activities: IMG -> Event Management -> Event Handlers and Event Handler Data -> Define Activities for Updating Event Handlers -> Multitask EH Update Activities -> Deactivate "Log Task" on your EH update activities.

2. Multitask EE Monitor Activities: IMG -> Event Management -> Event Handlers and Event Handler Data -> Expected Events -> Define Activities for the Expected Event Monitor -> Deactivate "Log Task" on your Multitask EE Monitor Activities

If you enable these log task then it will update in /SAPTRX/EH_TASK table and you can check in following path for each event handler /SAPTRX/EH_LIST -> Enter your event handler number -> Click Event handler detail view -> Select Tasks tab -> Tasks which are shown here also find in /SAPTRX/EH_TASK table.

Regards

GGOPII

[Former Member · Accepted solution]

Gopi,

Thanks for the information. I actually got most of this information from some of your other reports. I have removed the "Log Task" from all areas of config and I don't get any dumps. This is good for production from what I understand and I haven't required much need during config/debug because of application log.

What I don't understand is that if I check 'Log Task' on even 1 rule that is processed by an event I get the dump all of a sudden. And the dump occurs every time. After looking over the preprocessing logic I'm not sure what could possibly be causing the issue during preprocessing since that's the only new customization we have introduced.

[former_member186607 · Accepted solution]

Hi Jacob,

I guess the following has happened in your system:

Due to some custom logic, which can be direct inserts/updates of EH data or using RESEND activity to send event message to same EH again (to name two examples), there is an inconsistencie on the DB: In table /SAPTRX/EH_HDR the last sequence numbers for all dependent tables are stored (like LAST_TASK_NBR). If this value is inconsistent, the next INSERT on the table to which the incorrect last sequence number refers to, will cause a short dump.

In your case it seems that LAST_TASK_NBR is wrong and therefore as soon as any new task will be logged in table /SAPTRX/EH_TASK a dump will occur, since the sequence number is part of the key and the system will use a sequence number that has already been used before.

Please open an OSS message on this issue and let me know the number. Then we can provide you a note, which will provide you further information on this.

Best regards, Daniel

[Former Member · Accepted solution]

Daniel,

Within we have also run into an additional dump related to the '/saptrx/eh_evmsg' table when we trigger an event from an Event Type extractor. Should I also mention this dump in the OSS message? Are they related?

[Former Member · Accepted solution]

Daniel,

Please refer to 0000826656 2015.

Thanks

[Former Member · Accepted solution]

The OSS Incident assist resolved the issue. The tables were out of sync for many of the handlers. I believe this primarily because in one of our rule sets we forgot to check if reprocessing was occurring. This meant that the rulesets where be rerun for events that had already been triggered. Oops!!! We now appear back up an running without dumps. Let's hope it lasts a nice long time.

Thanks for all of the help and assistance.

[Former Member]

Hi Jacob,

Check this out.

https://scn.sap.com/thread/3787704

It's a different thread regarding same EH_TASK dump like yours.

See if it helps. I tried in my system with new create event, pre-processing and tasks logged. No dumps for me.

Thanks,

Vishnu

[Former Member]

Also, put a breakpoint in ( you need to enable task log though )

Class: /SAPTRX/CL_EH_PROCESS_MODEL and

Method: LOG_ACT_TASK

See how TASK_NBR is built and where it's getting the current values from ( FU or FO )?

Thanks,

Vishnu

[Former Member]

From Debug it appears that the EH_GUID for the FU rule tasks are the same....

[Former Member]

Additionally here are is the FU ruleset:

Why is the Z_CHECK_TREQ_CREATED not included in the task list? Would it be because the condition failed since I'm triggering 'LOAD_BEGIN'? Again though it doesn't make sense to me why the function is trying to insert the tasks from /SAPTRX/EH_TASK table with the same ID...

[Former Member]

Hi Jacob,

I do not think this is the issue. Your screen shot looks OK with different task ids. Can you let us know what's the value of i_table_name?

Try without your RESEND rule and with RESEND rule. Lets first narrow it down to make sure ZRESEND is the issue. Also can you send the screen shot of your resend ( double click the resend rule and add it here.

Yep, if condition fails, it will not be processed ( to your other question ).

Thanks,

Vishnu

Message was edited by: Vishnu Cheeti

[Former Member]

Vishnu,

I'm not sure how I could remove my ZRESEND rule for the FO through and be a valid test because the event won't go to the FU where the error is occuring? Are you saying let's see if the event reports to the FO handler?? I'm not really thinking it's the ZRESEND itself because the error appears to occur during the FU (AOT) processing of rules...

[Former Member]

My bad. I didn't read that the issue is on FU side. What's in Z_RESEND_TO_VMS_V2? Also, are you building any task_nbr or any seq_num explicitly?

Thanks,

Vishnu

[Former Member]

It's not getting to the Z_RESEND_TO_VMS_V2 so that's not the issue but this rule determines if the event should be further sent from a FU event handler to a VMS event handler.

I'm not sure what you mean by building a 'task_nbr'. We do maintain sequence numbers in the rules (I thought this was required for order)??

[Former Member]

I removed the Event Type (TM FO/FB Planned - Report 'ZTREQ_CREATED' Event) from executing and there is no issues reporting events to the FO handler and then during resend it sends to the FUs without issues and I can continue to report with no dumps.

The goal of the custom Event Type that we created is to report the event 'ZTREQ_CREATED' on the FO/FB handler being created.

[Former Member]

Hi Jacob,

Then look at the following thread. Steffen gave nice notes on the similar issue. Event Types and IDOC structure both build the data same way and this thread might help you as well.

FYI: I was talking about EH_TASK-TASK_NBR and EH_CNTRL-SEQ_NBR, but looks like it's data building in Event Types, you can ignore that.

Thanks,

Vishnu

[Former Member]

Vishnu,

After looking over the thread it appears to focus on sequence number. But I don't think the sequence number comes into play within the Event Type logic, correct?

[Former Member]

Hi Jacob,

Seq numbers are built in EM side based on the data from Event Type ( or/and pre-processing ). Atleast you know it's because of Event Type for your "Create Event" code.

Do you mind adding your code here? Not sure what I am looking for at this point in the code though, maybe parameters.

Thanks,

Vishnu