Assignment of Step type and CR step for MDG_S

[Former Member]

Hi

This is in continuaton for thread MDG_S workflow.

I original issue which is for MDGS when I assigned WS543000005 to CR type and sumitted CR goes no where,

As as per SWEL it  shows No Reciver Found enen though GET_AGENT table is maintained.

In another system I found that WS531000044 is assigned ti CR Type Then I tested it and found that CR creates Work Items also upto final processing.

as per below

• Before CR Submission : CR status is 02: Changes to be executed
• After CR Submission : CR status is 01:To be considered and Approved
• After CR Reviewer approves : CR status is 09: Dependant Data to be processed /Approved
• After Purchase reviewer Finalize processing :CR status is 09: Dependant Data to be processed /Approved
• After Finainace reviewer Finalixe processing :CR status is 09: Dependant Data to be processed /Approved
• Now I can not see CR any where even though CR step 04 and 04 assigned to my user ID

I have some questions as Description in Define Change Request Steps is not Mataching with description in GET_AGENT desesion table.

Also it is observed that step 80 is not assigned to WS531000044 in IMG node Define Change Request Steps but it can be seen in GET_AGENT decesion table and step no 06 and 07 does not appears in GET_AGENT decesion table ( In edit mode).

Can you explain from where assignment of  CR steps to CR type in desion table are taken ino accout ?

Why description is not matched for steps under IMG and in decesion table?

Can you explain me releationship between CR step and step type,CR Status and where they \maintained in IMG and how proceeses modelling is diffenent t for determination of Next CR step in case of WS531000044 ?

[Former Member]

First of all, the workflow template associated with the CR type in MDGIMG is the only workflow template to be instantiated when a CR of that specific CR type is submitted. The receiver type function module will read the CR type definition and return back the corresponding WF template number.

Second, there are two general categories of CR type workflow templates: hard-wired (this is my own term) and rule-based. Hard-wired workflow templates (like the simple two-step workflow template WS75700027, advanced MDG workflow template WS75700043, MDG-S workflow template WS53100044, MDG-C workflow template WS53100003, etc.) have a pre-defined set of step numbers. So, in reality it does not matter if you assign the step number in the workflow-template-to-step assignment table. Even if you change the step numbers, it won't make any difference because those step numbers are hard-coded in the workflow design itself (transaction SWDD). The second type is rule-based workflow template. There is the standard famous MDG rule-based workflow template WS60800086. And there is potentially custom copies of this workflow template that can be controlled using the same BRF+ applications maintained using transaction USMD_SSW_RULE (or the corresponding node in MDGIMG). The first type of workflow templates (hard-wired) can function without any additional configuration. The second type (rule-based) needs the corresponding configurations in order to be function: configurations such as step numbers, step descriptions, and BRF+ rules.

Coming to step descriptions table. This table contains a list of CR types along with their step numbers and descriptions. The main purpose of this table is to display the step description in the header of the CR task when a user is processing a CR step.

Now, if you notice when you are configuring the rule-based workflow, the description of the step actually shows up in the decision table. However, many times, the description displayed in the BRF+ editor is incorrect. This is a known bug (at least know to me) in the BRF+ editor. There could be an OSS note with a solution but I haven't checked. The BRF+ editor picks up the description of the first step with the given number regardless of the CR type which is a problem. So, if CR type ABC contains step 10 with description "ABC Approval" and CR type DEF contains step 10 with description "Review After Rejection", the BRF+ editor will display the text "ABC Approval" next to step 10 when configuring steps of CR type DEF. To prove my point, find a number that is not used in the step number table, add that number as a step to two CR types, assign each a different description, then add them in the BRF+ editor. You will see that it will always pick the first one.

I hope this helps explains some of the MDG workflow behavior you encountered. Please see this document Configuration of the Workflow - SAP Master Data Governance - SAP Library for more information about MDG workflow in general.

Also, take a look at this document for details on how to configure MDG's rule-based workflow template: .

[Former Member]

Hi Abdullah

Thanks for nice and detailed explains.

Can you explain from where assignment of  CR steps to CR type in desion table are taken ino accout ?or how CR determine Step/Process type associated with it depending upon CR status?

Can you explain me releationship between CR step and step type,CR Status and where they maintained in IMG ?

Above are releated to hard wired only (Pre delived by SAP)

Can you explain why MDGS WS531000044 template after displaying CR status 09: Dependant Data to be processed /Approved as CR not flows anywhere (Stuck)

[Former Member]

Please keep in mind that "hard-wired" workflow templates are just that: hard-wired. This means that a specific workflow template (for example WS53100044) will always have the same number of steps, each step will always have the same type and number, agents will always be assigned in the same way, and those can't be altered by configurations. To understand each workflow template's behavior, you can either open that template in transaction PFTC or SWDD, or alternatively, read the exact behavior in SAP Help documentation. You basically need to google the workflow template number and you should be able to find the description of each template's behavior (by the way, the number you type has an extra zero so if you can't find a match on Google, you will know why ).

Now, the assignment of CR steps to CR type is done in the workflow template itself and NOT in the decision table. See the first screenshot:

The step number above "should" correspond to what is in the configuration table (for readability and consistency of documentation purposes). However, if for some reason, it does not, the hard-coded value is the value that will actually be considered. So, in technical terms, the assignment of step numbers in MDGIMG has no influence on how the workflow template will behave. Again, the main purpose is for the corresponding description in the step number configuration table to show on the CR window.

The other thing is the step type. A step type purpose is mainly to indicate what set of buttons will show at the top of the CR window. The fact that step types are represented by numbers confuse a lot of people with step numbers. I would have personally preferred if step types were a 2-char field so that a clear distinction can be made between step types and step numbers. In any case, buttons on the CR correspond to actions and you can see in MDGIMG that you can assign step types to actions. SAP delivers a pre-defined set of step types and associated actions. Those must NOT be altered because they could break the standard workflow templates. However, you can create your own custom step types and link them with as many actions (standard or custom actions) as you like. But again, you can't assign those custom step types to hard-wired workflow templates. You can only use them in your custom workflow templates or in the rule-based workflow.

Now, the question is how does the hard-wired workflow know what step type to use. The answer is easy: you can either find that in the SAP Help documentation or in the workflow template definition in transaction SWDD. For the above screenshot, the step type is 2. You can find that if you double-click the task ID TS75707980 (or display it using transaction PFTC) and look in the "Cntainer" tab. In this case, this task will ALWAYS have type 2. Other tasks are assigned different step types or are more dynamic in the sense that they expect the step type to be passed from the main workflow template calling them. For example TS53200002 will always have type 7, TS60808005 will always have type 5, and TS60807954 accepts the step type dynamically. This last one is the one used in the rule-based workflow (hence it has to read the step type configured in the decision table).

I hope this answers you question. You definitely need some level of workflow design/build knowledge in order to be able to completely understand all of this. Hopefully, this gives you a good starting point.

[Former Member]

Hi Abdullah

Thanks very much. This is definately useful. Need one more help when I tried in IDES system it shows below error in WF technical details

In SWDD under container it seems that step type 2 is assigned to WS53100045 which is subworkflow then why CR is not showing no where? Why CR is not edited with Approve/Reject Action/button?

[Former Member]

You need to expand the failed node and find the exact spot where it failed. Also, since this is a standard workflow template, you should do some research in OSS using the message number or the exact message text and the workflow template number.

[Former Member]

Hi Abdullah

It is failed at node 000008  Fill or Delete Data and task assigned is TS53200002.

It seems that step type in container is 7 instead of 6 ( For Step type  7 only one action is assigned which is Flinalize Processing where as for step type 6 actions assigned as Approve as well Reject)