Infotype updation getting failed in workflow background step

[former_member307541]

Hi Experts,

I am facing a problem with info-type update in a workflow process.

I've implemented a class method for assigning to the workflow task, in that method I've used 'HR_INFOTYPE_OPERATION' Fm to update info type.

Please check my code attached below.

Problem is while i am executing the class method directly Info type was getting updated properly

But when i run the complete workflow cycle Only the first record of internal table 'it_item'

was getting updated.

I've tried all the possible ways to achieve it like

* Adding some Wait time

* Using submit Report in method

* Using Call Transaction in method..etc.

am i missing anything..

Please Help me to resolve this problem.

-Thanks In advance

Sundeep.

    DATA : infty           TYPE  prelp-infty,
           number          TYPE  p0001-pernr,
           subtype         TYPE  p0001-subty,
           objectid        TYPE  p0001-objps,
           lockindicator   TYPE  p0001-sprps,
           validityend     TYPE  p0001-endda,
           validitybegin   TYPE  p0001-begda,
           recordnumber    TYPE  p0001-seqnr,
           operation       TYPE  pspar-actio,
           tclas           TYPE  pspar-tclas,
           dialog_mode     TYPE  c,
           nocommit        TYPE  bapi_stand-no_commit,
           view_identifier TYPE  p0003-viekn,
           lw_return       TYPE bapireturn1,
           return          TYPE bapireturn1,
           lw_key          TYPE bapipakey.

    DATA : lt_item   TYPE TABLE OF zhcmt066a,
           ls_item   TYPE zhcmt066a,
           wa_item   TYPE zhcmt066a,
           it_item   TYPE TABLE OF zhcmt066a,
           ls_pa2006 TYPE p2006,
           lv_lines  TYPE sy-index,
           req_id    TYPE zhcmt066-req_id.

    CALL METHOD me->get_request
      EXPORTING
        im_req  = im_req
      IMPORTING
        request = request.
    req_id = im_req.

    IF request-app_level = 'FA'.        " To check the approval Level
      SELECT * FROM zhcmt066a
        INTO TABLE lt_item
        WHERE req_id = req_id
        AND approved = 'M'.
      IF sy-subrc = 0.
        LOOP AT lt_item INTO ls_item.
          READ TABLE it_item INTO wa_item WITH KEY req_date = ls_item-req_date.
          IF sy-subrc = 0.
            wa_item-rec_hrs = wa_item-rec_hrs + ls_item-rec_hrs.
            MODIFY it_item FROM wa_item INDEX sy-tabix TRANSPORTING rec_hrs.
          ELSE.
            APPEND ls_item TO it_item.
          ENDIF.
          CLEAR : ls_item,wa_item.
        ENDLOOP.
*     update infotype with all the selected records
        LOOP AT it_item INTO wa_item.
          ls_pa2006-pernr = request-pernr.
          ls_pa2006-subty = '10'.
          ls_pa2006-endda = wa_item-req_date.
          ls_pa2006-begda = wa_item-req_date.
          ls_pa2006-anzhl = wa_item-rec_hrs.

          CALL FUNCTION 'BAPI_EMPLOYEE_ENQUEUE'
            EXPORTING
              number = request-pernr
            IMPORTING
              return = return.<br>
          IF return IS INITIAL.
            infty          = '2006'.
            number         = request-pernr.
            subtype        = '10'.
            operation      = 'INS'.
            lockindicator  = 'X'.
            validityend    = wa_item-req_date.
            validitybegin  = wa_item-req_date.

            CALL FUNCTION 'HR_INFOTYPE_OPERATION'
              EXPORTING
                infty         = '2006'
                number        = number
                subtype       = subtype
                objectid      = objectid
                lockindicator = lockindicator
                validityend   = validityend
                validitybegin = validitybegin
                record        = ls_pa2006
                operation     = operation
                tclas         = 'A'
                dialog_mode   = '0'
              IMPORTING
                return        = lw_return
                key           = lw_key.
            IF lw_return-id = 'E' and lw_return IS NOT INITIAL.
              MESSAGE ID return-id TYPE return-type NUMBER return-number
                 WITH return-message_v1 return-message_v2 return-message_v3 return-message_v4.
            ELSEIF lw_return IS INITIAL.
              COMMIT WORK.
              WAIT UP TO 2 SECONDS.
            ENDIF.

          ELSEIF return-id = 'E' AND return IS NOT INITIAL.
            MESSAGE ID return-id TYPE return-type NUMBER return-number
               WITH return-message_v1 return-message_v2 return-message_v3 return-message_v4.
          ENDIF.

          CALL FUNCTION 'BAPI_EMPLOYEE_DEQUEUE'
            EXPORTING
              number = request-pernr
            IMPORTING
              return = return.

          CLEAR : infty, wa_item, ls_pa2006, return, lw_return, subtype,<br>                  operation, lockindicator, validityend, validitybegin.
        ENDLOOP.
      ENDIF.
    ENDIF.

[anjan_paul]

Hi,

Please check the role and authorization of wf-batch .

Thanks

[former_member307541]

Hello Raymond,

Thanks for the response, I've updated my code with the required corrections as per suggestions from yourself and Egor Malov. I've added few additional checks for 'lw_return' ( Return parameter of HR_INFOTYPE_OPERATION ) and clearing all the returns parameters and some input variables before ENDLOOP.

But the issue is not resolved. Please guide me.

[raymond_giuseppi]

• Don't forget to clear the RETURN parameter for each new record in the LOOP. (If the FM doesnt clear it itself, a previous Success or Error Message will prevent following records processing.)
• You checked RETURN after BAPI_EMPLOYEE_ENQUEUE but not after HR_INFOTYPE_OPERATION, could you also check it there. (But only once you apply the previous correction)

[raymond_giuseppi]

Once those steps performed, did you get some error in RETURN parameter (locked, application error, authorization, etc.)

[former_member186746]

Hi,

Please check differences in user parameters between your user-id and WF-BATCH. In HR parameter molga (countrycode) is used in many places like features and will influence SAP behaviour.

Kind regards, Rob Dielemans

[former_member307541]

Hello Rob,

Thanks for the response, Could you please throw some light that how user-id and molga will influence the behavior in our scenario.

[former_member186746]

Hi,

SAP HR uses the user parameter molga to determine behaviour. So if stuff works on the foreground using your user-id and stuff does not work in background (i.e. sy-uname = WF-BATCH) then you must focus on differences between the two.

From my experience adding a molga to the wf-batch user fixed workflow hr-masterdata update issues I had.

Kind regards, Rob Dielemans

[egor_malov]

Hi, Sundeep,

I think I would check the results of HR_INFOTYPE_OPERATION call in this code ( lw_return variable ). This variable's contents can be the answer to your question (or at least can give a hint).

[former_member307541]

Hello Malov,

Thanks for the response. I've Checked it in the debugging process I didn't found any constrains from lw_return while Debugging all the records are getting updated to Info type. Facing the problem only when processing the complete workflow cycle.

please help to find a solution for this.

[egor_malov]

Sundeep, I think Rob is right - the problem is the user. Here are some quick checks I would do before digging deeper:

- give all your roles to wf-batch for a while. if your code runs in the background after it, you can make sure it is authorizations;

- make code dump if HR_INFOTYPE_OPERATION . Thus you can make sure it is really HR_INFOTYPE_OPERATION than causes the problem ( add temporary code after the FM call like this: assert lw_return-type is initial or lw_return-type eq 'I' or lw_return-type eq 'S'. ).

[former_member307541]

Hi Malov,

I've checked the authorization status for wf-batch, it is having all roles authorizations.

- if the problem is with the authorizations it should update Zero records, But in our case a single (only the first ) record is getting updated from the internal table(it_item) with the same user wf-batch.

[egor_malov]

Some more things (not all relevant to the problem):

1. you describe your task as 'update' but in the code there is operation ='INS'. Is it correct?
2. you possibly have two commits: one is in your code, another in standard hr code due to optional parameter NOCOMMIT = ' '
3. you can use COMMIT WORK AND WAIT instead of COMMIT + WAIT UP TO ...
4. In this code you are not processing all possible options ( lw_return-id = 'S' etc )

          IF lw_return-id = 'E' and lw_return IS NOT INITIAL.
              MESSAGE ID return-id TYPE return-type NUMBER return-number
                 WITH return-message_v1 return-message_v2 return-message_v3 return-message_v4.
            ELSEIF lw_return IS INITIAL.
              COMMIT WORK.
              WAIT UP TO 2 SECONDS.
            ENDIF.