Issues with Approval Step in Subworkflow WS50000033

[Former Member]

Hi Folks,

as this is my very first post to SDN, here is a quick introduction: I've been involved with SAP and ABAP for almost 8 years (prior to that I did PL/1-development) but I'm completely new to Workflow (just had BIT601 two weeks ago). I already spent some time reading and searching through the SDN-Forums/Blogs/Wikis this site provides, but I guess, that I'm suffering from "information overload" - especially as I cannot really place all the provided information. I therefore hope, that I at least managed to place this question in the proper forum!

Now for my current issue:

I'm involved with a project to make use of the Manager Self Service (MSS) functionality provided by SAP. A colleague and I are trying to follow the information provided by SAP in these three documents: "Configuration Guide for the Personnel Change Request (Release 60.1)", "Developing your own personnel change requests (Release 50.1/50.2)" and "Internal Service Request (ISR) cookbook (July 2004)". We are running Netweaver 04, SAP Basis 620, SAP_HR 470.

As a prototype, we've managed to get scenario SPPD for "Change Position (enhanced)" set up in the MyHRManager-section of the portal. We can submit the form for one of the employees we've set up in the development system and we also see (via transaction SWEL) that Standard Workflow WS50000041 is triggered. Subworkflow WS50000033 is triggered as well but we are not able to get its first approval step to work. A "possible agent" is determined and it looks correct, but still, the work-item doesn't get a "responsible agent" assigned.

Checking out the container-elements, I can see that roleID 50000133 is passed into the subworkflow via field APPROVER1_ROLEID. Interestingly enough, standard task TS50000075 is using Rule AC50000134 for the agent-determination and I'm wondering if that could/should work or if this might not be the cause for our issue?

If I use transaction PFAC_DIS to test rule AC50000133, the system is able to determine the agent properly for the test-notification.

Did anybody experience this same or a similar issue when trying to get MSS set up for the first time?

Being new to Workflow and posting to SDN, I'm quite certain that I haven't provided all the necessary information yet. So please let me know if I need to provide more/other details.

Thanks and Cheers

Baerbel

[Former Member]

hi Baerbel,

Well I can think of followig check-points:

1. Check if the container element &APPROVERROLEID& has the value 50000133 (being passed by main workflow) or not ?

2. in the rule both the elements have been marked as mandetory. So check if both Notification and ApproverRoleId are having valid values.

check if these help u .. or atleast give sm direction.

regards,

Anuj Sethi

[Former Member]

Hi Anuj,

yes, as far as I can tell 50000133, gets passed in from the main to the sub-workflow and the notification number looks correct as well.

The thing is, that I'm not really sure if I'm looking at the correct container-information (too much information in the workflow-logs to really properly understand yet!).

This is what I see in the log for the two red "traffic lights" in step 4 "EVALUATE_AGENT_VIA_RULE":

Agent determination for step '0000000004' failed
Message no. SWF_RUN519

Diagnosis
An error occurred when determining users for step 0000000004. This error can be caused by a problem in the resolution of a rule for agent determination. See the additional messages within the workflow log.

System Response
If no recipients could be determined because the responsible agents determined do not belong to the possible agents of the task, the work item without recipients is set to the status ready.

If an error occurs in the execution of the rule for agent determination and if the corresponding indicator is set, the work item is set to the status error.

Procedure
Remove the cause of the error and start the workflow again using the administration environment.

Procedure for System Administration
The following agent determination failed: EXE

EXE Recipient 
NOT Notification when editing is complete 
LED Notification of missed latest end 
LST Notification of missed latest start 
DED Notification of missed requested end

and

Result of agent resolution does not agree with agents of task
Message no. SWF_RUN544

Diagnosis
When determining the recipient, the system established that none of the responsible agents determined belong to the possible agents of the task used in this step.

System Response
The work item is created without recipients and appears in no workflow inbox.

Procedure

Refer to your workflow system administrator.

Procedure for System Administration
Correct the agent assignment:

Check and if necessary change the assignment of the possible agents for the task used.
Check and if necessary correct the determination of the agent responsible.
In the workflow administration, choose Work items without agents and perform the agent determination for this work item again there.

I looked at transaction SWI2_ADM1 as indicated, but it didn't really provide any addiitonal information.

And before I forget: it won't do us a lot of good to contact the workflow-administrators as my colleague and I are supposed to fill that role

Thanks and Cheers

Baerbel

[martin_nooteboom]

Hi Baerbel,

First of all welcome to the forum. I must say you provide a lot more information than a lot questions we normally see, which is good.

Did you try testing rule 50000134 with the same data as in the workflow, maybe even debugging it? You say when you test rule 50000133 it gives back a result, is this also one of the possible agents? If not the task will not be delivered.

Regards,

Martin

[Former Member]

Hi Martin,

thanks for your quick reply!

Yes, I did test AC50000134 as well and stepped through it via the debugger. This ends with a termination and error OL356 in FM RH_GET_ACTORS for the same notifcation where AC50000133 works and - at least - produces a correct possible agent.

This is the place in the code where the error is triggered:

....
* execute function to resolve actor without evaluation path

          call function exec_fname
               tables
                    ac_container = actor_container
                    actor_tab    = actor_tab
               exceptions
                    others       = 1.

EXEC_FNAME leads to FM HRWPC_PCR_APPROVER where L_ROLE_ID is initial and error NOBODY_FOUND is raised immediately:

* get notification from container
  swc_get_element ac_container 'Notification' l_notification.
  swc_get_element ac_container 'ApproverRoleId' l_role_id.
  IF l_notification IS INITIAL OR l_role_id IS INITIAL.
    RAISE nobody_found.
  ENDIF.

Back in RH_GET_ACTORS the sy-subrc is evaluated:

        if sy-subrc > 0.

          if exec_enforce is initial.

            message id      sy-msgid
                    type    'S'
                    number  sy-msgno
                    with    sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4
                    raising exception_of_role_raised.

          else.

            message id      sy-msgid
                    type    'E'
                    number  sy-msgno
                    with    sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4
                    raising exception_of_role_raised.

          endif.
        endif.

So, it looks as if for whatever reason the role-ID doesn't make it into the processing even though the field seems to be filled in the container-element when the subworkflow is called. But then, there are quite a lot of structures/fields included in the container(s) and I'm not yet really sure which are the ones I need to focus on.

Thanks and Cheers

Baerbel

[martin_nooteboom]

Hi Baerbel,

I already tried to look at the workflow, but it is not available in the ECC 6.0 system I have access to now, so I couldn't help you there.

Regards,

Martin

[KKilhavn]

Hello, and I must second the opinion that it is nice to see a well explained problem for once. Not only well explained, you have tried to solve it yourself as well. It gives me some hope for the future of SDN.

Rule AC50000134 takes a rule ID as parameter, and if I have understood you right the value, 50000133 is passed to the rule container from the workflow.

Rule AC50000134 executes function module HRWPC_PCR_APPROVER, and one of the first things done after checking the parameters is a function call to RH_GET_ACTOR_ATTRIBUTES

for the rule ID that has been passed as parameter. When I execute that function module for AC50000133, the function module (export parameter execute_function) that is returned is HRWPC_PCR_APPROVER_NEXTMANAGER.

It is therefore strange that you say you end up in HRWPC_PCR_APPROVER. However, if you do, I think I know why there is no l_role_id. The function module RH_GET_ACTORS that is called takes a container. This container, when called from HRWPC_PCR_APPROVER, is the locally defined lt_act_container. As far as I could see, the values from the incoming ac_container are never copied to lt_act_container - however, this may of course differ depending on support packages. So, lt_act_container does not have the entry for ApproverRoleId that is found in the ac_container.

Sorry if this isn't very clear, but perhaps it may get you a step further.

<i>Message was edited by Kjetil Kilhavn:</i>

Got to go to a meeting, so I didn't have time for further examining now.

[Former Member]

Hi Kjetil,

thanks for your reply!

I tried to follow your information and from what I can tell FM RH_GET_ACTOR_ATTRIBUTES gets triggered for AC50000134 instead of AC50000133 and it then returns HRWPC_PCR_APPROVER.

While checking this out - also taking the previous reply into account - I ran transaction SWI2_ADM1 and used "Execute Agent Rules" while having debug-mode switched on. At first everything looked like it did before but then, in a "second pass" (?) through the processing it all of a sudden used AC50000133, returning HRWPC_PCR_APPROVER_NEXTMANAGER as the FM to use.

Subsequently, the work-item showed up with some more green lights and my colleague actually got it in his inbox (the two of us are the WF-Adminstrators and we've set up the PD-Org so that we can test this between the two of us - he is set up as my manager and I'm manager of a couple of folks for which I can trigger the PCR).

When my colleague tried to execute the WI, we ended up with more yellow-lights in the log, but this seems to have a different reason (something with the HTTP-connection).

Thanks and Cheers

Baerbel

[KKilhavn]

The first vs second pass probably depends on where you set the breakpoint. I suspect you have just started debugging, so when you're in RH_GET_ACTOR_ATTRIBUTES the first time it is actually when the workflow runtime engine is figuring out how to determine agents.

If you set a breakpoint in the function module for AC50000134 (i.e. HRWPC_PCR_APPROVER) then you will probably not see that, and both the first and second time you get into RH_GET_ACTOR_ATTRIBUTES it will be for AC50000133 (the first call is from HRWPC_PCR_APPROVER, the second from RH_GET_ACTORS. Just check the call stack in the debugger.

Additionally, you may already be aware of the "Cinderella" effect in workflow. If you assign possible agents etc these changes don't take effect until after midnight (application server time I suspect) since that is when all the buffers are refreshed. Refreshing buffers manually using transaction SWU_OBUF does however (almost?) always solve the problem.

[Former Member]

Hi Kjetil,

thanks for your additional information. What I don't understand is, that the workflow now gets at least a bit further in the process but that neither my colleague nor I are aware of any changes which could explain, why we don't get the agent-assignment-error any longer. The only thing I initiated while the WF was stuck was to go into SWI2_ADM1 and from there used "Execute Agent Rule" to see what would happen. I did this a couple of times w/o seeing any results and I then did it with debug-mode switched on and all of a sudden it is able to determine the responsible agent. In addition, if I now use PFAC_DIS to execute rule AC500000134 for a newly created notification, I get the error yet again. If I test AC500000133 for the same notification it works. Looking at the workflow-log for this new notification everything is green so far but it is stopped in step 4 "Approve Personnel Request" and shows my colleague as the correct responsible agent. This is really confusing!

After setting up our new test PD-Org-structure, I did refresh the org-environment but that was before I re-submitted a testform.

Now that we at least get the item in the appropriate inbox, we hit another snag. When we try to execute the workitem we get two errors:

1.

Work item 000000319008: Object method SWW_WW_EXECUTE_S cannot be executed

Message no. WL821

2.

HTTP handler for starting an external service cannot be read

Message no. SWK045

We tried to find the place in the code where these messages are triggered but struck out with a where-used for the messages, with debugging and even with utilizing ST05 to see which tables are used in the process. Searching OSS didn't help either. We are somewhat at our wits' ends....

Cheers

Baerbel

[KKilhavn]

My familiarity with HTTP extends not much further than the location field in Firefox ...

To find out more about the other error you can perhaps try transaction SWO1 to test execution (and debug) there? Normally that gives better insight, or even just studying the method's code can give better insight for experienced ABAP-ers. I can't be of much hands-on assistance I am afraid, since the solution is not in use here.

[Former Member]

Hi again, Folks!

We are still having the issue with the <b>HTTP-related</b> errors and don't seem to be able to find the root-cause for them.

1.

Work item 000000319008: Object method SWW_WW_EXECUTE_S cannot be executed

Message no. <b>WL821</b>

2.

HTTP handler for starting an external service cannot be read

Message no.<b> SWK045</b>

I did find a reference to WL821 in OSS where it says that this is usually a very meaningless message, but I didn't find anything for SWK045. Does anybody have any ideas which configuartion settings we might need to check and possibly modify? Unfortunately, neither my colleague nor myself really know what we need to be on the lookout for, so any information will be helpful.

Before we can progress with our project, we are fairly certain that we first have to get the SAP-supplied PCRs working - otherwise we'll later never know where any issues are coming from!

Thanks and Cheers

Baerbel