A journey into space ^H^H^H^H^H project system (2)

Another day with project structure BAPIs… I’ll take one really annoying error of the BAPI_BUS2054_CHANGE_MULTI function module as motive for writing the next part of A journey into space ^H^H^H^H^H project system (1)

As discussed in this article, a WBS element does have three presentations of its own:

• internal ID (rollname PS_POSNR, NUMC8), e.g. 00001234
• external unedited name (rollname PS_POSID), e.g. K1234567000010001000
• external edited name (rollname PS_POSID), e.g. K-1234567-000010.001

But that’s not all! I just got aware that there are two more presentation types:

• GUID (rollname SYSUUID_X), e.g. ECF4BBCFADA01ED5859FEBAD1603E0C4
• object number (rollname J_OBJNR), e.g. PR00001234

I think the the GUID will only be used for internal administration purposes.

The object number is a common SAP number that exists for nearly every “SAP object”. If you want to read the status of an object you will need to have the object number.

Internal ID

The internal id will normally be used in database tables. There is an option that also writes the external name of a WBS element into table PRPS-POSID_EDIT, but I did not find out how to set this option. If POSID_EDIT will be filled or not can be found out with function module CJPN_GET_FLG_EDIT. There is also a reorg report to set POSID_EDIT: R_FILL_POSID_PSPID_EDIT.

BAck to the internal id… This id will be stored in database tables where a WBS element can be attached to, like VBAP (sales order items). The use of the internal id guarantees a definite use. This also means that you could rename an existing WBS element and it is still properly attached to the objects.

Missing Functions

If there only was a function to rename a WBS element… But there is no BAPI that provides this functionality. There is also no BAPI that makes it possible to reassign a WBS element to another project. It’s really a pity if you want to build up your own structure.

Overview Of PS-BAPIs

The mother of all PS-BAPIs is the already mentioned BAPI_PROJECT_MAINTAIN. With this BAPI you can create projects, WBS elements and its structures (hierarchy and relation), networks and activities and activity elements.

All BAPIs concerning the WBS element begin with BAPI_BUS2054:

• BAPI_BUS2054_CHANGE_MULTI      Change WBS Elements Using BAPI
• BAPI_BUS2054_CREATE_MULTI      Create WBS Elements Using BAPI
• BAPI_BUS2054_DELETE_MULTI      Delete WBS Elements Using BAPI
• BAPI_BUS2054_GETDATA           Detail Data for WBS Elements

For accessing the network you will have to use these BAPIs:

• BAPI_BUS2002_CHANGE            Change Network Header Using BAPI
• BAPI_BUS2002_CREATE            Create Network Header Using BAPI
• BAPI_BUS2002_DELETE            Delete Network Header Using BAPI
• BAPI_BUS2002_GETDATA           Detail Data for Network Header

The subsequent objects of network, activities and activity elements, are processed with these BAPIs:

• BAPI_BUS2002_ACTELEM_CHANGE_M  List: Change Activity Elements
• BAPI_BUS2002_ACTELEM_CREATE_M  List: Create Activity Elements
• BAPI_BUS2002_ACTELEM_DELETE_M  List: Delete Activity Elements
• BAPI_BUS2002_ACTELEM_GETDATA   Detail Data for Activity Elements
• BAPI_BUS2002_ACT_CHANGE_MULTI  List: Change Network Activities
• BAPI_BUS2002_ACT_CREATE_MULTI  List: Create Network Activities
• BAPI_BUS2002_ACT_DELETE_MULTI  List: Delete Network Activities
• BAPI_BUS2002_ACT_GETDATA       Detail Data for Activities

For each object there is a BAPI where you can get the GUID of an object or vice versa:

• BAPI_BUS2002_GET*GUID*
• BAPI_BUS2054_GET*GUID*

For whatever these BAPIs will be needed…

Individual Behaviour of PS-BAPIs

All the mentioned BAPIs expect that you call the function BAPI_PS_INITIALIZATION at the beginning. This is properly described in the docu but differs to the use of all other BAPIs I knew so far. After this initialization you can call all of the mentioned BAPIs without any commit. That means you can create multiple WBS elements with multiple networks in a row.

Before doing the final commit you will have to call function module BAPI_PS_PRECOMMIT. This BAPI checks all formerly called BAPIs. If this BAPI returns no errors you must call BAPI_TRANSACTION_COMMIT. Otherwise you will have to do BAPI_TRANSACTION_ROLLBACK. If you don’t, the next commit will raise a short dump MESSAGE_TYPE_X:

FORM chk_precommit.

  DATA: chk_precommit_ok TYPE c,

        chk_error        type c.

  CALL FUNCTION ‘PS_FLAG_GET_GLOBAL_FLAGS’

       IMPORTING

            e_precommit_ok = chk_precommit_ok

            e_error        = chk_error.

  IF chk_precommit_ok = space.

*   Precommit wurde noch nicht aufgerufen.

    MESSAGE x030(cnif_pi).

Information-Message from BAPI_PS_PRECOMMIT:

No data has been changed, precommit will not be executed

This shortdump also will appear if you don’t catch all errors of the PS-BAPIs and call the BAPI_PS_PRECOMMIT anyway. But it’s not enough to catch errors of the PS-BAPIs to prevent the short dump. You also will have to catch success or info messages in case that no changes had been done within the BAPI!

So in my opinion it’s okay to bundle BAPI-calls with a PRE and a POST functionality, but the behaviour of all BAPIs alltogether is really kind of weird.

Misbehaviour 1

With the all-or-nothing-principle of the PS-BAPIs you can create diffrent WBS elements with multiple networks in nearly any order. I tried to first create a network then create a WBS element and the change the network to attach the created WBS element to the formerly defined network. But it didn’t work.

Not only that you will have to analyze the return table to get the temporary number of the created network, you will have to PRE-commit the changes first. that would have been okay if it worked, but it didn’t… Reason: The BAPI claims that the formerly created network cannot be changed…

But also the correct order does not work (first creating WBS element then create the network), because the BAPIs are in different function groups. And I guess the INIT and PRECOMMIT only work within one group…

Misbehaviour 2

Now let’s come to a really fat mistake in the BAPI_BUS2054_CHANGE_MULTI and the reason for todays post. I changed customer defined fields using the structure BAPI_TE_WBS_ELEMENT which contains the customer append CI_PRPS.

I set up the fields and did the only right and unicode-safe conversion with cl_abap_container_utilities=>fill_container_c. Everything worked fine. It worked well as long as I added to change standard fields at the same time. BAPI_BUS2054_CHANGE_MULTI can handle both structures at once (just as I expected):

Importing-Tables:

• IT_WBS_ELEMENT contains the standard structure of a WBS element
• IT_UPDATE_WBS_ELEMENT defines which fields of the structure should be changed
• EXTENSIONIN holds the customer defined data

The first thing the BAPI does is to convert the given WBS element to the edited form. That’s ok. As long as the BAPI further on does not tries the following:

* move extension with standard customer include CI_PRPS to prps_chg

  loop at extensionin where structure      = ‘BAPI_TE_WBS_ELEMENT’

                      and   valuepart1(24) = i_wbs_element-wbs_element.

VALUEPART1 of the EXTENSIONIN-structure holds the WBS element number, that’s true, BUT IN EDITED FORMAT!!

K-1234567-000010 is NOT EQUAL to K1234567000010000000!!!!

I’m fed up for today.

Maybe see you next time for Part 3.