Using SWE_EVENT_CREATE_FOR_UPD_TASK

[Former Member]

Hi,

About 5 months ago I posted asking how to raise an event for an asynchronous task that creates a document. I had some great replies, but now I am actually implementing this for the first time using the finction module SWE_EVENT_CREATE_FOR_UPD_TASK.

I have a problem in that I seem to be unable to get the instance linkage correctly populated with the object key; it is always empty.

In my workflow, I have a new object ZWGBU2032 subclassed from BUS2032. This is in an asynchronous task and the terminating event is bound such that the container element WIOBJECT_ID is object type ZWGBU2032 and event CREATED. The binding is from &_EVT_OBJECT to &_WI_OBJECT_ID.

In the sales order save user exit, I am calling my own function module in the V2 task:

    
    CALL FUNCTION 'ZWG_EVENT_ZWGBU2032_CREATED'
      IN UPDATE TASK
      EXPORTING
        VBELN         = VBAK-VBELN.

This function module then invokes in its body:

 
  L_OBJECT_KEY = VBELN.
 
  CALL FUNCTION 'SWE_EVENT_CREATE_FOR_UPD_TASK'
    EXPORTING
      objtype                       = 'ZWGBU2032'
      objkey                        =  L_OBJECT_KEY
      event                         = 'CREATED'
*     CREATOR                       = ' '
      START_WITH_DELAY              = 'X'
      TAKE_WORKITEM_REQUESTER       = 'X'
    tables
      event_container               = container_instanz
     EXCEPTIONS
       OBJTYPE_NOT_FOUND             = 1
       OTHERS                        = 2.

I have checked that the object key has a value when debugging the update task, but the instance linkage never receives it.

Can anybody please tell me why this may be so?

BR,

Tony.

[Former Member]

have you tried SWE_EVENT_CREATE_IN_UPD_TASK ...

regards

[pokrakam]

Hi Tony,

Beside-the-point question/suggestion: any particular reason for messing around in nasty Sales Order user exits <shudder> instead of using change documents? Change docs are far easier (SWEC, doc type VERKBELEG).

Also, you should delegate and use BUS2032.CREATED.

Lastly, you cannot wait for CREATED with an instance linkage! CREATED implies that it doesn't exist (usually), instance refers to an actual instance - with a key. Until the propellerheads working on wormhole theory get the time travel bit sorted you will not know what key to wait for when creating a SO.

Cheers,

Mike

[Former Member]

Hi Mike,

curiously there was a post here in this forum that described , how the .Created-Event links to a workitem instance waiting for it as a terminating event. The way, I imaged, it had to work, is that the event handling system stores the currently processed workitem (the "requester") and on event processing it finds the correct workitem id this way ?!?!

Anyhow you could be right that it never worked this way

Hi Juan,

I would propose the following solution that'll work pretty much safer:

- Derive & delegate object type WORKINGWI

- Add a new event WorkingWi.BUS2032_created

- Add a parameter to this event of object type BUS2032

- Use this event as a terminating event

- Change your user exit as following:

Use function module SWO_QUERY_REQUESTER to find the

workitem-id of the currently processed workitem.

(yes, the creation VA01 must be called using the

workitem).

Put the element BUS2023 with your vbak-vbeln as an

event parameter

Use the WI_ID as the object key and raise event

WorkingWi.BUS2032_created

- This passes your newly created business object BUS2032

to the event linkage of your workitem. Create a dataflow there to pass the new object back to the workflow.

[pokrakam]

Hi Florin,

Indeed it does, it is one of those 'special' bits of workflow. Might even have been my post My point about it being impossible without a really neat portable wormhole was specific to Tony's comment:

"I have a problem in that I seem to be unable to get the instance linkage correctly populated with the object key; it is always empty."

OK, technically a wait for CREATED also lives in the instance linkage table, but keys are nevertheless irrelevant.

Background: The requester an undeclared event parameter in CREATED events and all handled nicely black-box-style (i.e. it just works) when using change documents - hence my question why using MV45AFZZ.

Cheers,

Mike

[Former Member]

Hi Mike,

thank you for the clarifications!

Best regards, Florin

[Former Member]

Hi Mike,

Well I tried to implement the event creation from the change document, but I couldn't get it to work properly.

I looked at transaction SWEC, and added my object ZWGBU2032 event CREATED for the OnCreate of the Change Document. Problem is I coudn't get the event triggered when my order was created (I am using BAPI_SALESORDER_CREATEFROMDAT2 to do this).

I then tried to do the same thing from the wizard SWU_EWCD, which did the same thing.

In order to use create the event for the creation of a socument, I had to use transaction SWED to allow VERKBELIG to trigger events for creation (default is for change and delete only).

The BUS2032.CREATED event is triggered, but not ZWGBU2032.CREATED, which is the object bound to on the terminating event of my task.

That's why I tried to use the Function Module; although I was indeed then triggering the ZWGBU2032.CREATED event, the problem is still that the instance linkage created has an empty object key.

For my asynchronous task that waits for the terminating event, I am binding &_EVT_OBJECT& to &_WI_OBJECT_ID&.

I don't completely understand how the instance linkage appears and how it decides what object key it is waiting for before the document has been created (it was explained to me elsewheres but still hasn't really sunk in), so this is still a bit of a black art for me; if it works, I don't complain, but if it doesn't, I'm lost).

As for the wormhole theory part; I thought it was all a bit 'wormholey' too, but the section written about it in 'Practical Workflow for SAP' on page 372 gave me the impression that this is how it should be used:

" Your own program code that creates a new object should include this function module, which picks up the last work item as the work item requestor before raising the event, so that the terminating event can be correctly matched to the waiting work item. Make sure the call to this function module is made after the application object update in the update sequence, but before COMMIT WORK".

That's why I used the FM, and why I created is as a FM to update in the V2 task. Could well be that I have got the wrong end of the stick here though.

Cheers,

Tony.

[pokrakam]

Hi Tony,

My copy of the book seems to have disappeared into one of them wormholes, but I suspect you may have mixed up the object key and the workitem key. This is not really all that intuitive, took me a while to get my head around it, but just trust that it works.

Anyhow, you should be using delegation. From the front screen of SWO1, Utilities->Delegate. This is basically a 'reverse inheritance' particular to SAP. A delegated object's attribs, methods and events will automatically appear as part of the supertype. So, once ZWG... is delegated to BUS2032, you should ONLY use BUS2032 in your WF's - as in BUS2032.ZMYMETHOD and so on. Then, as you've already discovered, you can simply use BUS2032.CREATED. Simple, no coding required

Cheers,

Mike

[Former Member]

Hi Mike,

One thing I just noticed in the SAP documentation (sometimes it is even useful): Transaction SWED (Assignment Change Documents / Workflow Object Types) - the entry for VERKBELEG has not got the flag "Create Instance" set, which apparently means it cannot be used as a terminating event in a workflow. It is also recommended not to mess with the SAP standard settings, which this is.

So what do I do? Mess with it and set it as checked, or create a new change document type?

BR,

Tony.

[pokrakam]

Hi Tony,

Stick to the stadard document type. As I said before, you should be using BUS2032 in your WF, and you already have a BUS2032.CREATED event happening - so it should all work, no?

If it doesn't work, you can always try it out - I don't have a system available right now to check.

Cheers,

Mike