Update Sales EH before Deleting Delivery EH from application system

[former_member271212]

I have placed an enhancement implementation into IF_EX_LE_SHP_DELIVERY_PROC~SAVE_AND_PUBLISH_DOCUMENT I plan on creating an event for an unexpected event called "DeliveryDelete" which will update the Sales Order EH.

Should I be using the function module /SAPTRX/PROCESS_EVENTS since we are using ASYNC QRFC's??

Or is there a better way of sending this event?

[former_member583013]

Alex,

Just a quick note that SAP EM does allow you to post events to deativated EH's. This implies that you follow the process of deactivating the EH and not deleting it when the AOT is deleted or no longer relevant. Then you can still post events against it should you wish to do so. You just have to specify which events you wish to post against a deactivated EH before they will post.

Thanks

Kevin

[former_member271212]

Kevin,

Are you saying there is a way to keep an EH when the AOT is deleted (in standard SAP no enhancement)?

[former_member583013]

Yes. See the EH Deactivation Indicator on the Used AOT screen (General Data Tab).

The help for the field reads:

Event Handler Deactivation Indicator

Indicates that an event handler for an application object is deleted (set indicator) if the application object is no longer relevant.

The standard behavior of the application interface is that an event handler, which is created in the Event Manager, is not deactivated or deleted unless the corresponding application object or business object is deleted. This means that an event handler stays active, even if the condition for the event management relevance of an application object becomes false, having previously been true, due to changes to the corresponding business object.

Examples

A container as part of a shipment is moved with carrier A. Shipments of carrier A are event management relevant. If the carrier is now changed to B, which is not event management relevant, the behavior is as follows:

- Indicator is not set: Event handler stays in the Event Manager.

- Indicator is set: Event handler is deleted after carrier switch.

[former_member271212]

lol...your funny Kevin, I have seen that help screen a few times

[former_member271212]

Well after having solved the issue for deletion of a delivery I am now running into larger problems within the shipment.

When a delivery is removed from a shipment in the SHIPMENT_ITEM_NEW table that is passed the TKNUM is removed. In the SHIPMENT_ITEM_OLD however this information remains and as expected is listed with the UPDKZ indicator listed as D.

So now the link from master to main can no longer be created and I need this information again for functionality in the event types for AO Type ESC_SHIPMT.

Unfortunately SAP is providing the tables this way so if we look at the BADI IF_EX_BADI_LE_SHIPMENT~BEFORE_UPDATE

structure IM_SHIPMENTS_BEFORE_UPDATE it has table reference NEW_VTTP which contains...

MANDT TKNUM TPNUM VBELN TPRFO ERNAM ERDAT ERZET PKSTA KZHULFG UPDKZ

300 0 80001880 1 GAP4 20100730 194730

Notice TKNUM is initial TPNUM is initial and UPDKZ is initial

but the OLD entry has all of this information.

This actually results in an error in the application log as well...

Referencing of main and master table fields VTTPVB - VTTKVB failed

Message no. /SAPTRX/ASC039

Diagnosis

Referencing between the main table fields and the associated master table fields could not be completed.

System Response

Processing is aborted for the current application object.

Procedure

Check the settings for the application object type within the transaction for defining application object types.

[former_member190756]

Hello Alex,

only possibility that i see would be to create your own BADI implementation and recognize this case. If this case happens then fill the table for SHIPMENT_ITEM_NEW with the info from the OLD table and set deletion indicator to D.

Best egards,

Steffen

[former_member271212]

Kevin,

I have left the update field alone (as I found other problems with this). But I believe I have found the solution that will work best for our company. In the BADI implementation /SAPTRX/LE_SHIPPING interface IF_EX_LE_SHP_DELIVERY_PROC~SAVE_AND_PUBLISH_DOCUMENT there are a series of FM's that SAP uses to build up the data and configuration done from the IMG.

Instead of re-inventing the wheel to try and make the BAPI /SAPTRX/BAPI_EH_ADDEVENTMSG_02 work and pull in all of the correct data. I have put an implicit enhancement in /SAPTRX/LASC2F06 form skipflag_handling at the very top. This now allows the deleted AO's to run through the Event Types one last time before the AO is deleted.

This is the code I have put in the enhancement.

ENHANCEMENT 1  Z_EM_DELETE.    "active version
*Allowing for further checks on deleted EH's for event types
  IF sy-uname = 'GAP4'.
    BREAK-POINT 'GAP4'.

    DATA: ls_aoalltabs TYPE /saptrx/aoalltab.
    FIELD-SYMBOLS: <lfs_field>.

        ASSIGN COMPONENT is_objtype-mainupdatefield
                     OF STRUCTURE is_maintab_ref TO <lfs_field>.

      READ TABLE it_all_obj_tabs INTO ls_aoalltabs
               WITH KEY tabledef = is_objtype-maintabdef
                        BINARY SEARCH.

      if ls_aoalltabs is not INITIAL AND
         <lfs_field> is ASSIGNED.
        IF <lfs_field> = ls_aoalltabs-deletevalue.
          cv_skipflag = ' '.
          EXIT.
        ENDIF.
      ENDIF.
  ENDIF.
ENDENHANCEMENT.

In our Event Type Relevance we already check for the deletion, therefore giving back the true control of the Event Type back where it should be in my opinion.

I also wish that SAP would add criteria to allow for an EH to remain active even if the AO is deleted. All of the data could still be pulled into BI that way and we could send a de-activation when the deletiion occurs.

Thanks again for the messages!

[former_member583013]

Alex,

You would need to code for this in the BAdI IF_EX_LE_SHP_DELIVERY_PROC~SAVE_AND_PUBLISH_DOCUMENT.

Check for deletion prior to calling the EM communicate FM and call the add event BAPI.

[former_member271212]

The problem I have Chithaanantham is that this is not even on the EM side.

On the application side when you delete a delivery it checks this and places a skip indicator so that no event types get checked at all. It doesn't even hit the relevance for the event types.

So would there be another way in the Application (ECC) side of the house during a deletion to make this happen?

The only other way I can see this possible is in an enhancement spot, which in my opinion is going to be a complete duplication of code.

[former_member271212]

As I dug further in the code I found that in the include /SAPTRX/LASC2F06, this is where it starts skipping the event type checking.

In the code at line 630...

*   Check if table record is updated / new
  cs_appobj_ctab_wa-update_indicator = upd_indicator-trackserver.
  IF cv_skipflag IS INITIAL AND
              NOT is_objtype-mainupdatefield IS INITIAL.

Going to my business process type tables I removed the update field name from ESC_DELIV, DELIVERY_ITEM_NEW, now all of my events are being checked even upon deletion. Does anyone know what harm this solution might cause in other areas? What is the update field truely used for?

*OLD*

DELIVERY_ITEM_NEW LIPSVB LIKP UPDKZ I U D

*NEW*

DELIVERY_ITEM_NEW LIPSVB LIPS I U D

[chithaanantham_janakirama]

Dear Alex ,

Please do not unmark the update field in Business process type and AOT , Please check the following points

1. Rule set maintained in delivery event handler type in EM customizing .

2. There should be a seperate rule ,codition ,activity with in the rule for updating the "Sales order EH "

3. If there are more than one rule maintained , please analyze the conditions and activity functionalities with in the rule maintenance .

Customizing for SAP EM under Event Management Reactions to Event Messages Define Rule Sets .

Hope this information help you find the solution for the same .

Best Regards ,

Chithaanantham

[former_member583013]

If the standard SAP EM AI is not called for the deletion event then you should call the BAPI /SAPTRX/BAPI_EH_ADDEVENTMSG_02 as per normal to create the event. Just call it in background task after setting the queue name:

call function 'TRFC_SET_QUEUE_NAME'

exporting

qname = iv_rfc_queue_name

exceptions

invalid_queue_name = 1

others = 2.

Then call the BAPI and the commit work:

call function '/SAPTRX/BAPI_EH_ADDEVENTMSG' "#EC EXISTS

in background task

destination is_trxsrv-rfcdest

exporting

simulate = space

• BLOCKONERRORIN =

synchronous = 'X'

• BUFFER_MODE =

eh_generation_mode = 'N'

tables

trackingheader = lt_bapi_evm_header

tracklocation = lt_bapi_evm_locationid

trackaddress = lt_bapi_evm_address

tracklocationdescr = lt_bapi_evm_locdescr

tracklocadditionalid = lt_bapi_evm_locaddid

trackpartnerid = lt_bapi_evm_partnerid

trackpartneraddid = lt_bapi_evm_partneraddid

trackestimdeadline = lt_bapi_evm_estimdeadl

trackconfirmstatus = lt_bapi_evm_confstat

tracknextevent = lt_bapi_evm_nextevent

tracknextevdeadlines = lt_bapi_evm_nextevdeadl

trackreferences = lt_bapi_evm_reference

trackmeasuresults = lt_bapi_evm_measresult

trackstatusattrib = lt_bapi_evm_statusattr

trackparameters = lt_bapi_evm_parameters

trackfileheader = lt_bapi_evm_fileheader

trackfileref = lt_bapi_evm_fileref

trackfilebin = lt_bapi_evm_filebin

trackfilechar = lt_bapi_evm_filechar

tracktextheader = lt_bapi_evm_textheader

tracktextlines = lt_bapi_evm_textlines

extensionin = it_extensionin

extensionout = it_extensionout

return = ct_bapireturn.

if not iv_rfc_queue_name is initial.

call function 'TRFC_SET_QUEUE_NAME'

exporting

qname = iv_rfc_queue_name

exceptions

invalid_queue_name = 1

others = 2.

endif.

• Commit posting

call function 'BAPI_TRANSACTION_COMMIT' in background task

destination is_trxsrv-rfcdest.

Edited by: Kevin Wilson on Apr 14, 2010 2:18 PM