Problem in triggering the correct workflow on AdobeForm submission for PCR

[Former Member]

Hi All,

I am facing a problem involving triggering of workflows through Adobe form submission. I have created a scenario for "Employee seperation" in QISRSCENARIO transaction and assigned it to an approval workflow. I have also activated and assigned the BUS7051-Created event in the workflow Basic Data. My workflow also triggers perfectly when i submit the adobe form. Everything is perfect till here.

Now i have to create another scenario for "Request for Transfer" Now for this i had to create a seperate workflow. My problem is since both these workflows are assigned to the same event whenever i submit the "Employee seperation" form both the workflows get triggered. <b>Is there a setting where i can configure the corresponding workflow to be triggered for the respective scenario's alone?</b> How do we handle this situation?

[Former Member · Accepted solution]

Hi,

I think you are using Notification Type 56 for all your Custom Scenarios. Why dont you create your own Custom Notification Type and use it for your Custom Scenarios. These Notification Type can be created in SPRO...

Cross Application Components - Notification - Notification Type - Define Notification Types. Here, copy the Standard Notification 56 into your own NType.

And use this Notification type as a Condition for triggering the Workflow.Please attach this in the Basic data - Start Events.

I hope this should clear your problem.

Regards,

<i><b>Raja Sekhar</b></i>

[Former Member]

Thanks Raja...Would try that and get back to you..

[Jocelyn_Dart]

Prasath,

Another option is to put a start condition on your workflow's event linkage so that it only starts for that specific scenario. This is a very common approach to handle PCR/ISR scenarios.

First make sure your workflow event linkage to BUS7051.CREATED has been activated.

Then go to transaction SWB_COND and ask to create a start condition. Search for the BUS7051 object and CREATED event. I find it helps to use the "Technical names" options as well. Identify your workflow, and create a condition against it using a logical expression such as

"bus7051.scenario = ZABC"

Save and then activate the start condition.

This way you can use the same notification type for all your PCRS if you wish - and you don't have to change your QISRSCENARIO configuration at all.

Regards,

Jocelyn

[Former Member]

Hi Jocelyn,

We are on ECC 50.

There is no Attribute <b>SCENARIO</b> in the BOR - <b>BUS7051</b>. So how do we put a condition in this case?

Regards,

<i><b>Raja Sekhar</b></i>

[Jocelyn_Dart]

Hi Raja,

We generally create a delegated subtype of BUS7051 and add a <b>scenario</b> attribute based on VIQMEL-AUSWIRK.

Advantage of this approach (i.e. using start conditions) is that you can also expose any other attribute you want to use to separate your workflows.

E.g. you can even use virtual attributes to call ISR_SPECIAL_DATA_GET and return the value of a characteristic. The characteristic doesn't need to exist in all forms of course - you just leave the matching attribute empty if its not relevant.

Very very handy especially when dealing with many forms.

Regards,

Jocelyn

[Former Member]

Thanks Jocelyn,

Till now, I was using Simple Business Object's method(that calls ISR_SPECIAL_DATA_GET) to get the characteristics data into Workflows.

Now, I feel your approach is more interesting and handy.

Thanks for the reply.

Regards,

<i><b>Raja Sekhar</b></i>

Message was edited by: Raja Sekhar

[Former Member]

Hi Prasath,

Is your problem solved?

Regards,

Raja Sekhar

[Former Member]

Hi Raja/Jocelyn,

Couldnt try the solution really yet as we were held up with some other issues. Will check that and close the thread asap. Thanks for your help.

[Former Member]

Hi Jocelyn/Raja,

I am trying to use SWB_COND for differentiating between the different workflows. I have created a virtual attribute W_SCENARIO_KEY for this. I tried populating this scenario key by using the following staement,

<b>

CALL FUNCTION 'ISR_SPECIAL_DATA_GET'

EXPORTING

notification_no = object-key-number

IMPORTING

SCENARIO = w_scenario_key.

SWC_SET_ELEMENT CONTAINER 'W_SCENARIO_KEY' W_SCENARIO_KEY.</b>

When i try to include W_SCENARIO_KEY as a start condition the workflow shows up an express message and fails to trigger. In ST22 i can see that there is an exception "INVALID_NOTIF_NUMBER" raised.

But if i don't set this as a start condition all the workflows activated to BUS7051-CREATED are triggered and in the WF logs i can see the correct value of W_SCENARIO_KEY for the respective notification number.

I am not sure why this happens when i set it as a start condition alone.

I instead used a select statement as shown below,

<b>select * from viqmel into table itab_VIQMEL

where qmnum = object-key-number.

loop at itab_viqmel where qmnum = object-key-number.

w_scenario_key = itab_viqmel-auswirk.

endloop.</b>

After inserting this statement it works fine without any issues. Any idea on why ISR_SPECIAL_DATA_GET cant be used in the virtual attribute implementation?

The following is the dump i get if i use ISR_SPECIAL_DATA_GET,

Information on where terminated

The termination occurred in the ABAP program "SAPLQISR9" in

"ISR_SPECIAL_DATA_GET".

The main program was "RSWDSTRT ".

The termination occurred in line 39 of the source code of the (Include)

program "LQISR9U01"

of the source code of program "LQISR9U01" (when calling the editor 390).

Source Code Extract

Line SourceCde

9 *" EXCEPTIONS

10 *" NO_INTERNAL_SERVICE_REQUEST

11 *" INVALID_NOTIF_NUMBER

12 *" INT_SERVICE_REQUEST_NOT_FOUND

13 *"----

---

14

15 * local data

16 DATA: lt_dummy TYPE qisrsgeneral_param.

17

18 DATA: lr_isr_document TYPE REF TO cl_isr_xml_document.

19

20 DATA: ls_notif TYPE qmel.

21

22 * MAIN

23 * try buffer first

24 CALL FUNCTION 'ISR_SPECIAL_DATA_BUFFER_GET'

25 IMPORTING

26 ET_SPECIAL_DATA = special_data

27 ED_SCENARIO = scenario

28 EXCEPTIONS

29 BUFFER_EMPTY = 1.

30

31 IF sy-subrc eq 0.

32 EXIT.

33 ENDIF.

34

<b> 35 * check notification number

36 SELECT SINGLE * FROM qmel INTO ls_notif

37 WHERE qmnum = notification_no.

38 IF sy-subrc NE 0.

>>>>> RAISE invalid_notif_number.

40 ELSEIF ls_notif-auswirk IS INITIAL.

41 RAISE no_internal_service_request.

42 ENDIF. </b>

43

44 * set scenario

45 scenario = ls_notif-auswirk.

46

47 * read ISR XML document

48 CALL METHOD cl_isr_xml_document=>read_for_display

49 EXPORTING id_notif_no = notification_no

50 IMPORTING er_isr_xml_document = lr_isr_document

51 EXCEPTIONS bds_error = 1.

52

53 IF sy-subrc NE 0.

54 RAISE int_service_request_not_found.

55 ENDIF.

56

57 * read data from XML document

58 CALL METHOD lr_isr_document->get_data_from_xml

[Former Member]

Hi,

Can you check if the NOTIFICATION NUMBER is being properly sent as input to that FM? Kindly check that at runtime in DEBUGGING MODE and let us know if this has a value.

Regards,

<i><b>Raja Sekhar</b></i>