cancel
Showing results for 
Search instead for 
Did you mean: 

Equipmen dismantle, change plant, install does not work

Former Member
0 Kudos

Hello experts,

I have developed a function module which should execute the following steps:

- dismantle an equipment from a functional location

- change the plant of the equipment

- install the equipment into a new functional location

I therefor tried to use these three existing function modules:

- Dismantle -> EQUIPMENT_DISMANTLE

- Change Plant -> BAPI_EQUI_CHANGE

- Install -> EQUIPMENT_INSTALL

Now the problem occurs that the call of the BAPI_EQUI_CHANGE does not execute a commit so the changes are not directly written to the database and the following call of EQUIPMENT_INSTALL is not able to install the equipment into the new functional location.

I tried to execute a BAPI_TRANSACTION_COMMIT after the BAPI_EQUI_CHANGE but still it does not work. In my dev system I can insert a "WAIT UP TO 1 SECONDS." call which work but this does not work in the testing env. Also this is a very bad approach.

The curious thing is that everytime I debug my FM everything is working fine. So I bet there is a problem in the direct following call after the BAPI_EQUI_CHANGE and EQIPMENT_INSTALL.

Here are the relevant calls:


CALL FUNCTION 'EQUIPMENT_DISMANTLE'
    EXPORTING
*     READ_SOBJ             = 'X'
*     READ_ROBJ             = 'X'
*     LOCK_SOBJ             = 'X'
*     I_DATE                = SY-DATUM
*     I_TIME                = SY-UZEIT
      i_inherit_flags       = p_i_inheritance_flags
      old_sequi             = p_i_ls_equi
*     EXEC_MEAS             = ' '
      transmit_new          = 'X'
      direct_new            = 'X'
      commit_new            = 'S'
    CHANGING
      s_equi                = p_i_ls_equi
*     R_EQUI                =
*     R_IFLO                =
    EXCEPTIONS
      err_dismantle         = 1
      OTHERS                = 2
            .

  p_rc = sy-subrc.

  IF sy-subrc NE 0.
    CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
      EXPORTING
        wait   = 'X'
      IMPORTING
        return = bapiret2.

  ENDIF.

*...

  itob-maintplant   = p_target_swerk.
  itob-planplant    = p_target_iwerk.

  itobx-maintplant  = 'X'.
  itobx-planplant   = 'X'.

  CALL FUNCTION 'BAPI_EQUI_CHANGE'
    EXPORTING
      equipment               = p_ls_equi-equnr
      data_general            = itob
      data_generalx           = itobx
      data_specific           = itob_eq
      data_specificx          = itob_eqx
*     VALID_DATE              = SY-DATUM
*     VALID_TIME              = SY-UZEIT
    IMPORTING
*     DATA_GENERAL_EXP        =
*     DATA_SPECIFIC_EXP       =
      return                  = bapiret2
            .

  IF bapiret2 IS INITIAL.

    CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
      EXPORTING
        wait   = 'X'
      IMPORTING
        return = bapiret2.

  ENDIF.

*...

  CALL FUNCTION 'EQUIPMENT_INSTALL'
    EXPORTING
      read_sobj             = 'X'
*     READ_ROBJ             = 'X'
*     LOCK_SOBJ             = 'X'
*     POSEQUI               =
*     I_DATE                = SY-DATUM
*     I_TIME                = SY-UZEIT
      i_inherit_flags       = p_i_inheritance_flags
*     OLD_SEQUI             =
*     EXEC_MEAS             = ' '
*     CALL_EXIT             = ' '
*     CHECK_NEW             = 'X'
      transmit_new          = 'X'
      direct_new            = ' '
      commit_new            = 'X'
    CHANGING
      s_equi                = p_ls_equi
      r_equi                = p_ls_equi_target
      r_iflo                = s_iflo
    EXCEPTIONS
      err_install           = 1
      OTHERS                = 2
            .

How can I enable this inside one function module?

Please, any hints are welcome!

Regards,

Andreas

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Andreas,

So I bet there is a problem in the direct following call after the BAPI_EQUI_CHANGE and EQIPMENT_INSTALL.

You are right here. Me also faced almost the same issue.

Andreas, can we make use of the the statement SET UPDATE TASK LOCAL, which will help you to switch your updates from in update task (VBLOG entries) to a local LUW.So the update will happen in the current work process and not in the update work process.

Some important things you need to notice here is that at the beginning of every SAP LUW, the local update function is deactivated. If you wish to use it, you must reactivate it again before the first update function module is registered.

Please refer the SAP help available for this ABAP statement.

Hope your problem will be solved...

If not please dont forget to update the solution, which in turn will be a great help for for all SAP people including me.

Regards,

Antony Thomas

Former Member
0 Kudos

Hi Antony,

thanks for the hint, but this does unfortunately not work as it is not allowed to call the FM BAPI_EQUI_CHANGE with the 'IN UPDATE TASK' statement. I also tried the abap call 'COMMIT WORK AND WAIT' instead of the bapi call but still no luck.

And I tried the FM EQUIPMENT_MODIFY which did also not worked with the given hints.

What can I try else? Anyone knows maybe another FM to change the plant information for my equipment?

Former Member
0 Kudos

OK, a minor step forward but still problems.

I got the plant changes working by using the FM 'EQUIPMENT_INSTALL'. Nevertheless the following FM 'EQUIPMENT_INSTALL' still does not install the newly changed equipment into the functional location.

I have a commit statement between these two calls but this wasn't successful.

Thats why I still need help and a solution why a change and an install function module working on an equipment do not work together in one FM when called one after the other.

Update:

Still working: When using a 'WAIT UP TO 5 SECONDS' command between the two FM, it is installed correctly, but this isn't secure in productive env. So I need a solution to solve the time and access problem on my equipment change.

Edited by: Andreas Krienke on Jul 23, 2010 3:41 PM

Former Member
0 Kudos

Hi Andreas,

Why a change and an install function module working on an equipment do not work together in one FM when called one after the other.

See these two FMs are working in 'in update task mode', so all in update task FMs will log data into table VBLOG and at the end only all these vblog entries will commit togther. This is the fact behind these issue. you may be aware about it.

Now we are trying some implicit commit to excecute first VBLOG entry.

During debug mode automatic commit will happen.

What we can do is call first BAPI in one FM and then at the end of this FM one commit will happen, then call next BAPi from second FM. We can avoid wait statements here.

Regards,

Antony Thomas

Former Member
0 Kudos

Hi Antony,

thanks for your answer. It's getting clearer now. But unfortunately I want to have only one call from external system to sap. So if there is any chance that we can build it in one function module it would be perfect.

Any further hints?

Former Member
0 Kudos

Hi Andreas,

Inside the function module help of BAPI_EQUI_CHANGE, it is suggesting commit work and wait( in the case of matnr/ sernr change.) But here I dont think you people have a serial number change is happening during equipment dismantle. If so SAP is suggesting commit work and wait only.Please see below.

If you call the BAPI to change the material and/or serial number of the equipment, a Commit Work and Wait must be run after each BAPI call.

What we can do is, if frequency of this entire operation is high, first dismantle all the equipments(say 100 EQUNR) then commit work and wait for say 5 seconds. Then call the install FM in loop.

Am not sure, just an idea!

Regards,

Antony Thomas

Edited by: Antony Thomas on Jul 26, 2010 5:19 AM

Former Member
0 Kudos

So, what I have done now is the following:

IF bapiret2-type EQ 'S'.

    COMMIT WORK AND WAIT.

*   now check if changes are written to db
    DO.
      l_iwerk = 0.
      " get the latest item entry
      SELECT SINGLE iwerk FROM equz
        INTO l_iwerk
        WHERE equnr EQ p_ls_equi-equnr AND
              datbi EQ '99991231'.

      IF l_iwerk EQ equitime-planplant.
        p_rc = 0.
        EXIT.                 " data written to db -> exit
      ELSE.
        WAIT UP TO 2 SECONDS. " wait and check in next loop
      ENDIF.

      IF sy-index EQ 10.
        p_rc = 1.             " set returncode to 1
        EXIT.                 " after 10 times -> exit
      ENDIF.

    ENDDO.
  ENDIF.

This code checks if the respective entry in the db is already written and if not retry to read it with a delay of 2 seconds.

Looks a little bit ugly but does the job.

If anyone could get me to a "better" solution I would be happy to hear!