cancel
Showing results for 
Search instead for 
Did you mean: 

No Administrator found for the task (solution in FAQ not applicable sadly)

Former Member
0 Kudos

Hi All,

I have had to build a custom work item inbox due to complex client requirements, one of which being that all tasks are declared as "General tasks", so that all users can select and work them.

Work item execution is performed using the function module SWL_WI_DISPATCH (I've also tested using SAP_WAPI_EXECUTE_WORKITEM), which sometimes returns the error 'No administrator found for the task'.

I followed the standard instructions for this error message, refreshing the org assignments, transaction SWU_OBUF etc, and this did not help the issue.

The error seems to occur within the function module RH_WI_AGENT_EXECUTE_CHECK, however according to our configuration I can see no reason why users shouldn't be allowed to execute the work item, if the org assignment has been stable for several months, all tasks are generic, and the work item status is READY. There is no rule for determining agent beyond them being "General task"s.

Does anyone have any ideas? According to the data in SWWWIHEAD I can't see any reason why execution should be failing for these work items.

Thanks

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

From where you are trying to access the workitems

From SBWP. If its is from SBWP it should be fine. If you are trying to check workitem from workflow log and try to execute workitem which are not yours you should reserve the workitem.

Please check.

Thanks

Arghadip

Former Member
0 Kudos

We're accessing the workflow from a custom report. Basically an ALV grid showing relevant entries from SWWWIHEAD.

The easiest way to replicate the issue is as follows:

User A selects a work item, then forwards it to user B.

User A then attempts to work the work item (or forward it to user C); but the fm SAP_WAPI_EXECUTE_WORKITEM is called, it fails with the error "No administrator found for the task".

I assume that there is some authorization check being invoked behind the scenes, as the work item was technically forwarded. However, since user B has not yet worked the work item, I can't see a way around the issue. Any other suggestions? Using the standard transaction is not possible due to performance constraints.

pokrakam
Active Contributor
0 Kudos

>

> User A then attempts to work the work item (or forward it to user C); but the fm SAP_WAPI_EXECUTE_WORKITEM is called, it fails with the error "No administrator found for the task".

>

> I assume that there is some authorization check being invoked behind the scenes, as the work item was technically forwarded. However, since user B has not yet worked the work item, I can't see a way around the issue. Any other suggestions? Using the standard transaction is not possible due to performance constraints.

Actually now this makes perfect sense. The error is usually related to an inconsistency in the agent assignment (hence the 'usual' resolution is to refresh the buffers). In your case you've forwarded the item and are trying to execute it with a user who no longer has it. You need to either:

  • Add logic into your report to refresh and/or make the item unavailable after forwarding

  • Take ownership of the item before execution. SAP_WAPI_RESERVE_WORKITEM might do the job.

Former Member
0 Kudos

Mike, you seem to be on the right track - though when I attempt to reserve the workitem prior to execution it gives the error that "You are not a receiver of the work item".

Are there any other function modules out there that can assert control of work item like this?

pokrakam
Active Contributor
0 Kudos

I had a suspicion it may not work. In that case you need to forward it to the executing user (should be able to do so via WAPI).

Alternatively - not sure what your scenario is about - there is an authorization object to allow administrative execution (as per SWIA), but this should not be used for a standard user, and certainly not for standard business functions.

Former Member
0 Kudos

Forwarding the item by FM to the executing user did the trick, thanks!

Now to figure out how to allow the functionality without blasting huge holes in our security....

Really appreciate your help here, thanks.

As an aside - is there any simple logic for determining whether an item is currently in a "forwarded" state? I know I can query the SWWUSERWI table, though this looks like a fiddly query - are there any function modules out there that do this?

pokrakam
Active Contributor
0 Kudos

>

> Now to figure out how to allow the functionality without blasting huge holes in our security....

I'd suggest making sure your agent assignment is correct to start with and also performing a check that the user trying to execute it is one of the responsible agents for the work items (SAP_WAPI_GET_AGENTS or something like that).

> As an aside - is there any simple logic for determining whether an item is currently in a "forwarded" state? I know I can query the SWWUSERWI table, though this looks like a fiddly query - are there any function modules out there that do this?

FM SAP_WAPI_GET_HEADER

--> header-wi_forw_by is not initial.

Former Member
0 Kudos

Hi there,

almoste there

The new extended eMail notification do allow a feature, which is named "Forward by eMail" (in the general settings of SWNCONFIG). And the result is, that a work item can be executed by another user-id, who is not the actual receiver of the work item.

If you looked at report RSWNWIEX you'll find out that exactly the proposed solution is in use there, having a very usuable example already in place: (check lines 155 and following)


      CALL FUNCTION 'SAP_WAPI_EXECUTE_WORKITEM'
        EXPORTING
          workitem_id    = p_wi_id
*  .....
      IF lv_rc <> 0 AND cl_swn_settings=>wi_forward_via_mail = 'X'.
*-         require to put back if WI is selected
          CALL FUNCTION 'SAP_WAPI_ADM_WORKITEM_BACK'
*  ....
            CALL FUNCTION 'SAP_WAPI_FORWARD_WORKITEM'
              EXPORTING
                workitem_id   = p_wi_id
                user_id       = sy-uname
*  ...
              COMMIT WORK.   "Needs to be done before executing again
*   ...
                  CALL METHOD cl_swf_run_wim_factory=>initialize( ).
                  CALL FUNCTION 'SAP_WAPI_EXECUTE_WORKITEM'

That doesn't blast a security hole, as far as I see.

Using the table SWWUSERWI directly is not advisable at that time, I'd say.

Best wishes,

Florin

Former Member
0 Kudos

That did the trick nicely Florin! Thanks very much guys, I really appreciate all of the help here.

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi,

Check the way you are assigning agent to the worktiem. There might be some issue. Let us know.

Regards,

Niraj