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

I am an ABAP programmer since 1994. I started with SAP release 2.1i. Since then I coded a lot of reports, programs, dynpros, classes, lists, forms and so on. I used pure ABAP, functions, exits, dirty-assigns and BAPIs. I ran through different modules like, FI, CO, SD, MM, WM and others. Each module has its own specialties. Some are good, some are bad. Each module has its own approaches to dealing with different problems.

That’s okay. SAP is a complicated product where a lot of different people worked on. But some things should always be the same. Some things should always work the same way. BAPIS for example.

But they don’t.

Coding BAPIs

Normally (where normally is the way I used to get known to BAPIs) the programming of BAPI’s looks like this:

CALL FUNCTION ‘BAPI_object_CREATE’

   exporting

     header = header_data

   tables

    items  = item_table

    return = return_table.

CALL FUNCTION ‘BAPI_TRANSACTION_COMMIT’.

You fill out the necessary fields and call the BAPI. After the call you will have to check if there where errors. If not you have to call BAPI_TRANSACTION_COMMIT. Otherwise you need to call BAPI_TRANSACTION_ROLLBACK.

If you want to change an object, there also exists an update-structure where you have to check the fields to be changed.

From The Scratch

Let’s go back to the module project system. When I first get in contact with programming the project system there were a lot of naming confusions due to german and english words and abbreviations.

The following objects will appear in the project system:

• project number
• WBS elements (WBS = Work Breakdown Structure) (DE: PSP-Element)
• networks (DE: Netzplan not Netzwerk)
• activities (DE: Vorgang not Aktivität)
• activity elements (DE: Vorgangselemente)
• components (DE: Komponenten)
• milestones (DE: Meilensteine)

The Project number and also the wbs element have three different appearances:

• internal number ( type NUMC length 8), e.g. 00001234
• external unedited number (type CHAR length 24), e.g. K1234567000010100000
• external edited number (type CHAR length 24), e.g. K-1234567-000010.100

Now let’s have a look on the used rollnames:

Sometimes the rollname PS_PSP_PNR is used. For project definition and also for wbs element… sometimes you need the rollname for internal value without having the conversion exit, e.g. PS_POSNR1

Conversion Exits

There are different Conversion-exits you need to convert from internal to external and vice versa.

CONVERSION_EXIT_ABPSP_OUTPUT – Convert internal wbs element number into external (edited)

CONVERSION_EXIT_ABPSP_INPUT – Convert external wbs element number to internal

Mostly the wbs element is stored in internal format in the database tables. All the BAPIs work with external view. But sometimes the unedited view is used, sometimes the edited view. So it might be possible that you will have to convert from unedited to edited view.

In table PRPS where the wbs elements are stored, the POSID (= external number) is saved as K1234567000000000000, but you don’t see, because there is a conversion exit on the field.

Quite obfuscating…

For converting project numbers you will use conversion-exit ABPRJ or KONPD.

These are the prerequisites I started with…

BAPI_PROJECT_MAINTAIN – Method “Save”

Now I will go into some special characteristics of the PS-BAPIs. As mentioned before, the PS-BAPIs behave a bit different to the ones I knew before.

This BAPI is the silver bullet of programming the project system. You can build a complete project structure with this function module. The idea of this BAPI is that you can call the BAPI multiple times. At the end you commit the changes.

Additionally to the needed structures and tables (project definition, wbs elements, networks, activities, …) you need to fill the methods table. In this table you need to define all the actions to be processed (Create Network NET00001, UPDATE NetworkActivity NETW000010010, …). At least you need to save the changes using command Save.

The first contact with this BAPI caused a lot of trouble because the booking was asynchronously. The structure we had to build was very complex so that we had to call the BAPI a multiple times but always with a commit at the end to have the concrete objects that the BAPI created.

We did some LOOPs and CHECKs and WAITs to be sure the expected object had been created (I’ll come back to the reason).

Asynchronous behaviour is normally caused by the delayed processing of update tasks which are called in a separate task. You can cope with this behaviour by coding SET UPDATE TASK LOCAL which  forces the update task to be processed in the current LUW.

But not this BAPI. Just for fun I started a cross reference of BAPI_PROJECT_MAINTAIN to hopefully find some hints.

The first usage of this BAPI lead me to a valuable hint: Instead of using command Save, the program used the method SaveAnd Wait.

Bämmm. Nothing more to say about that. Useless to say that the documentation did not even give a little hint to that. Searching for solutions also was hardly possible until I had the right key word “SaveAndWait”.

BAPI_PROJECT_MAINTAIN – Calling In Update Task?

Let’s make it short: Calling this BAPI in update task is not possible! Why? Most BAPIs use internal function modules inside the BAPI. That’s ok. It’s important that the BAPI does not change the outside.

The BAPI_PROJECT_MAINTAIN has another speciality. I will shortly describe in bullet points:

• Exporting each importing parameter TO MEMORY
• SUBMIT program R_BAPI_PROJECT_MAINTAIN
• Inside program R_BAPI_PROJECT_MAINTAIN
  • Define local data structures corresponding to the importing parameters
  • Importing each parameter FROM MEMORY
  • Call function  2054_PROJECT_MAINTAIN
  • Export returning parameter TO MEMORY
• Importing returning parameter FROM MEMORY

SUBMIT can not be used in update tasks…

Why SAP did it in this crude way is documented in the BAPI itself:

* this function wrapps the BAPI call, to provide a cleared work area

BAPI_PROJECT_MAINTAIN – Using With Custom Fields

I previously mentioned that we had to completely commit the changes to the structures we made. The reason is that we are using customer fields on activities. The custom fields (append to table AFVU) cannot be updated with BAPI_PROJECT_MAINTAIN.

To set or change the custom fields you need to use BAPI_BUS2002_ACT_CHANGE_MULTI.

I will talk about the special features of the BUS2002-BAPIs in the next blog post.

It’s really hard to implement business functions. It’s even harder if there are obstacles like the ones I’ve mentioned in this article.

to be continued…