cancel
Showing results for 
Search instead for 
Did you mean: 

Asynchronous Business Object Event not triggering Workflow

Former Member
0 Kudos

Hello everybody,

I created a workflow for processing of inbound messages (IDoc). The workflow is correctly started when an IDoc arrives. Then it prepares some data and runs into a waiting step. After the user processes the messages via a custom transaction, the workflow should proceed and send some additional information to the message origin.

I created a new BO with an event ProcessComplete, which is called in the custom transaction via the following code:


INCLUDE <cntn01>.
DATA lo_zisu TYPE swc_object.

swc_container lo_container.
swc_create_container lo_container.
swc_set_element lo_container 'VAR1' lv_var.
swc_create_object lo_zisu 'ZABC' lv_object_key.
swc_raise_event lo_zisu 'ProcessComplete' lo_container.

But when I call this code, the workflow does not continue. When I use SWEL to manually create an event on this object, the workflow only continues when I set the check box "synchronous call". So in some way, the asychronous calls disappears completely.

Can anyone give me a hint, where to look for these calls? May there be a setting not active on the system for this particular workflow? Other workflows with the same method of event handling work well.

Thanks and regards,

Christoph

Accepted Solutions (1)

Accepted Solutions (1)

surjith_kumar
Active Contributor
0 Kudos

Hi,

In T.code we42 you can configure to trigger the event.

Refer this [Link|https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/609e6465-15de-2a10-859d-da7bcbca54a3].

Regards,

Surjith

Former Member
0 Kudos

Hello Surjith,

just to clarify: The workflow is started correctly when the IDoc is received. But than it has a waiting step, which should be ended via a custom report. After that the workflow should continue. But this does not happen.

So I think, I don't need a process code for this event, as there should not be called any function module.

Am I wrong?

Regards,

Christoph

former_member185167
Active Contributor
0 Kudos

Hello,

The code you listed above, is it run in the foreground or the background?

I ask because I've always believed that checking "Trigger receiver FM synchr" causes the event creation to happen in the foreground. Not sure if this has anything to do with it.

So when you run that code, does the event actually get created - do you see it in SWEL? With the expected key? I assume you've already checked this, but just in case.

regards

Rick Bakker

Hanabi Technology

Former Member
0 Kudos

Hello Rick,

the code I posted is called in foreground, but the macro eventually calls an l_event->raise method, which is run in background via trfc.

In SWEL, there is no entry. When I debug, I get RC=0 and an event ID, but this ID is not present in SWEL. I assume it is some kind of BO/event customizing problem, but I don't know exactly where to look for it.

Regards,

Christoph

former_member185167
Active Contributor
0 Kudos

Hello,

If I understand correctly:

When you use SWUE and check the "Trigger receiver FM synchr" box, it works (ie workflow continues).

When you use SWUE and don't check the "Trigger receiver FM synchr" box, it doesn't work

(ie workflow does not continue).

But now you're saying you don't see an entry in SWEL? For either case?

You must have the event trace turned off, surely. Please go to SWELS

and turn it on and try again.

If it's really the case that the event only has an effect when generated in

the foreground, then that's probably the problem that need to be fixed.

regards

Rick Bakker

Hanabi Technology

Former Member
0 Kudos

Hello Rick,

when I called the event via SWUE syncronously, there is an entry in SWEL, otherwise not.

So I think the event is somewhere not processed when called in the background.

Regards,

Christoph

former_member185167
Active Contributor
0 Kudos

Hello,

That is very strange and sounds like it could be a bug - SWUE should create the event whether the checkbox is marked or not. The only possibility I can think of is that background jobs are being queued and the queue is stuck or is hopelessly full. I'm not sure where to find this, you should look in OSS.

Are you using the event queue?

regards

Rick Bakker

Hanabi Technology

Former Member
0 Kudos

Hello,

I debugged deeper into the whole issue. When I call the function module for the event creation directly (not via the macro posted in my initial post), I have the option to control syncronous va. asynchronous processing:

CALL FUNCTION 'SWE_EVENT_CREATE'
  EXPORTING
    objtype              = 'ZISU_MDC'
    objkey               = lv_objkey
    event                = 'ProcessComplete'
    start_recfb_synchron = 'X'
  IMPORTING
    receiver_count       = lv_rcvcnt
    event_id             = lv_evtid
  TABLES
    event_container      = lo_container
  EXCEPTIONS
    objtype_not_found    = 1
    OTHERS               = 2.

The export parameter start_recfb_synchron controls this. In the program flow, the following is the difference between the two ways:

Synchronous:

      CALL FUNCTION im_handler->m_linkage-recfb
           DESTINATION im_handler->m_linkage-rfcdest
           EXPORTING
             sender                   = l_sibf_object_por
             event                    = l_sibf_event
             rectype                  = l_sibf_rectype
             handler                  = l_receiver_por
             exceptions_allowed       = 'X'
             xml_size                 = l_xml_size
             event_container          = lt_xml_container
           IMPORTING
             result                   = l_result
           EXCEPTIONS
             temp_error               = 1
             OTHERS                   = 99.

Asynchronous:

      CALL FUNCTION im_handler->m_linkage-recfb
           IN BACKGROUND TASK
           AS SEPARATE UNIT
           DESTINATION im_handler->m_linkage-rfcdest
           EXPORTING
             sender                   = l_sibf_object_por
             event                    = l_sibf_event
             rectype                  = l_sibf_rectype
             handler                  = l_receiver_por
             exceptions_allowed       = ' '
             xml_size                 = l_xml_size
             event_container          = lt_xml_container
             .
      CALL FUNCTION 'ID_OF_BACKGROUNDTASK'
           IMPORTING
                tid = l_trfc_id.

The first one works fine, the event gets processed, there is an entry in SWEL, the workflow continues. The second way does not work. The second function returns a tRFC ID, but when locking tRFC in the debugger and search for the call via SM58, there is no entry.

In parallel I opened an OSS message, but did not get any (useful) response yet.

Regards,

Christoph

former_member185167
Active Contributor
0 Kudos

Hello,

Thanks for the update. This is an interesting problem, I'll see if I can replicate it.

Are you using the event queue?

regards

Rick Bakker

Hanabi Technology

Answers (1)

Answers (1)

Former Member
0 Kudos

I have executed one of my custom Event and workflow and i have not faced such an incident.

Could you please check once by putting the COMMIT WORK statment as when we raise the event

normally Commit statment is required.

Former Member
0 Kudos

Hi,

COMMIT WORK does not change anything.

Any different ideas?

Thanks and regards,

Christoph

former_member185167
Active Contributor
0 Kudos

Hello,

Are you sure the correct key is being used, ie one that matches the one the workflow is waiting for?

You say "I use SWEL to manually create an event". How do you do that?

Do you mean SWUE? If so, where is the "synchronous call" checkbox?

Which version are you using?

regards

Rick Bakker

Hanabi Technology

Former Member
0 Kudos

Hello,

sorry, of course I meant transaction SWUE. The object key is the same the program uses to raise the event. Under debugging tools, there is an option "Trigger receiver FM synchr.". When I use this option, everything works fine. If it is not set, the workflow does not continue.

I am using NetWeaver 7.00, ECC 6.03 and IS-U 6.03.

Thanks and regards,

Christoph