cancel
Showing results for 
Search instead for 
Did you mean: 

Avoid triggering of Travel Request WF On Change

Former Member
0 Kudos

Hi guys,

I've copied and customized WF 20000050. I've added a Form Step so a travel coordinator can enter or modify travel services. After this step, a new workflow is being triggered. What would be the best approach to avoid this?

Thanks,

Raúl

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

Hi,

WebDynpro ABAP is always starting the ..CREATED and ...CHANGED Event same time in certain releases.

Also, depending on your WF, certain actions inside your WF may trigger a CHANGED Event, which is unwanted

To avoid this, add some basic checks to a custom function module during WF start in SWETYPV, like "no stat if WF-Batch triggerd CHANGED event" or "only start if trip status eq 3/1" or "only start if created in WebDynpro ABAP"

sample:

FUNCTION Z_FITV_CHECK_EVENT_CHANGED.

*"----------------------------------------------------------------------

*"*"Lokale Schnittstelle:

*"  IMPORTING

*"     VALUE(OBJTYPE) LIKE  SWETYPECOU-OBJTYPE

*"     VALUE(OBJKEY) LIKE  SWEINSTCOU-OBJKEY

*"     VALUE(EVENT) LIKE  SWEINSTCOU-EVENT

*"     VALUE(RECTYPE) LIKE  SWETYPECOU-RECTYPE

*"  TABLES

*"      EVENT_CONTAINER STRUCTURE  SWCONT

*"  EXCEPTIONS

*"      NO_WF_START

*"----------------------------------------------------------------------

* Check function for Travel-Workflow WS90200005 (

* prüft WF-Batch

  INCLUDE <cntn01>.

  DATA: trip          TYPE swc_object,

        lv_last_chgby   type swc_object,

        lv_userid LIKE USR01-bname,

        creator LIKE sy-uname.

* Get object Trip

  swc_create_object trip objtype objkey.

* last

  swc_get_property trip 'LastChangedBy'  lv_last_chgby.

* get UserID

  swc_get_property lv_last_chgby 'ID' lv_userid.

* Creator of this event (who chreated the trip)

  swc_get_element event_container '_evt_creator' creator.

* WF-Batch?

  if creator = 'WF-BATCH' or lv_userid = 'WF-BATCH'.

    RAISE no_wf_start. "rectype.

  endif.

*

ENDFUNCTION.

rgds, Michael

Lukas_Weigelt
Active Contributor
0 Kudos

Hi Raúl,

now this one's tricky and interesting. In terms of approaching your problem, Murali is basically correct, i.e. maintaining a start conditiojn in the Event Firing of the WF template; however I doubt the parameters provided by the Container will let you distinguish between end user and travel coordinator (except for the field "Transaktion" maybe this one differs indeed and you can use it as an indicator, you'll have to check that).

You should NOT touch the generic SWE-Event Handler Function Module, because it's used not only in one module.

In case the approach Murali suggested isn't feasible because the parameters don't allow for a distinction, then you could still try some tweaking over the ABAP Memory. Let me know if the Start-Condition Approach doesn't work for you, then I'll go more into detail.

Cheers, Lukas

Former Member
0 Kudos

Hi,

Before going to avoid triggering a workflow, first you should know why it is triggering.

Check,

1. Why another workflow is triggering ? in which case? Is that workflow related to previous one?

You can trace which event is triggering that workflow in SWEL (you should switch on trace in SWELS)

2. If you don't want to trigger the workflow, simply deactivate the event linkage of the workflow in SWE2.

Regards,

Murali Krishna.

Former Member
0 Kudos

Thanks for the reponse Murali!

The event REQUESTCREATED (BUS2089) is getting triggered twice. The second time gets triggered when FM PTRA_WEB_EXPENSE_REPORT_SAVE_2 is executed to save travel services.


   CALL FUNCTION 'PTRA_WEB_EXPENSE_REPORT_SAVE_2'

     EXPORTING

       i_employeenumber   = ftpt_req_head-pernr

       i_tripnumber       = ftpt_req_head-reinr

       i_trip_component   = 'R'

       i_general_data     = wa_general_data

       it_req_service     = it_service

     IMPORTING

       ev_saved_successful = v_saved_success

     TABLES

       et_return          = it_return.

Regards,

Raúl

Former Member
0 Kudos

Hi Raúl Mora,

So, you mean, the same workflow is triggering twice? If it is like that, it is better to maintain a start condition for your first workflow in the 'Start events' of the workflow or in Check function module in SWE2 tcode.

Regards,

Murali Krishna.

rafael_lopez011
Explorer
0 Kudos

correc