Changing UNAME in table CDHDR from WF-BATCH to unique username

[Former Member]

Hello everybody,

the situation is as follows:

Within a Workflow a SAP document needs to be released. During the Workflowprocess the Workflow executes a Business Object method to realese the document. Therefore, being processed within Workflow the UNAME in the change history (tables CDHDR and CDPOS, relevant is table CDHDR) is WF-BATCH.

But the customer would like to have the user's name here, who triggered the BO method for releasing the document.

Simple idea:

Just change the field UNAME in table CDHDR as desired via a function module.

Now what is the problem:

Our function module is called within the Workflowprocess and nothing happens with the saved WF-BATCH in the field UNAME of table CDHDR.

But if we run the funtion module seperatly (not within Workflow but with our logged on user) the change to the above field and table works well.

We already checked for all kinds of authority problems, user WF-BATCH already has the authority rights for "SAP ALL".

Thanks in advance to everybody who has an idea for solving our problem!

Kind regards,

Alex

[former_member182466]

Are you sure the CDHDR entry has been written to the database when you call your FM? Would be easy to check in the FM.

Change documents are one of the last things to get written to the database in the update task.

[Former Member]

Hi Gert,

what you are saying is one thing we already had in mind as well.

So to give you and everybody else more technical details:

There is one (SAP Standard) function module for the release of a document and within this function module is also the change to the CDHDR table.

The COMMIT WORK should be done not later than this function module has finished processing (that's what I'm supposing and what the coding looks like).

Our function module for the change to the CDHDR table is running within a own Work Item after the the Work Item with the release step.

So from this point of view there shouldn't be a problem with the data written (or not written) to the database, should be...?

Kind regards, Alex

[Former Member]

Hi Alexander,

There might still be an update issue if your release step is based on a synchronous task.

In that case, even if you put you function call to update CDHDR in a separate workflow step, the update from the previous (i.e. the release) step might not be done yet when the CDHDR update is running.

So if your release step is synchronous, just make it asynchronous (you'd have to find an event occuring when you release the document to use as terminating event).

Definitely worth a try.

KR,

Patrick

[Former Member]

Hi Patrick,

I'm visiting the customer next week and then will try it asap.

My feedback will follow soon after but in the meantime, if anybody else has another idea, please let me know.

Thanks Patrick and to everybody else.

Kind regards, Alex

[former_member182466]

Hi Alex,

change documents are not processed in the same database LUW as the business object changes, the first is done in [V2 update task|http://help.sap.com/saphelp_nw70/helpdata/en/e5/de870535cd11d3acb00000e83539c3/frameset.htm] while the latter is done in V1. It is therefore possible that your workflow step to update the CDHDR happens before the change document is actually written to the database. Timing gets even more critical if the transaction does not use COMMIT AND WAIT but just COMMIT.

I think you could also solve your problem if you had your own updates happen in V2 update task, you need to check 'Start delayed' instead of 'Start immed.' in the Processing Type section of the FM attributes. And you will of course need to use CALL FUNCTION ... IN UPDATE TASK.

I am curious about your code. How do you determine in your FM what entries in CDHDR to update?

Greetings,

Gert.

[Former Member]

Hi Gert,

this is also an idea I had in mind, but I'm not (very) familiar with the SAP LUW and the update process.

I think for testing, this is easier to handle than to modify the workflow, so I will check this opportunity first. Sorry Patrick...

As I mentioned above, I will be back at the customer next week and give my feedback to you all soon after the testing.

Thanks for your help and everybody enjoy your weekend!

Kind regards,

Alex

EDIT:

I forgot to answer the last question:

To select the right entries of table CDHDR only the keys OBJECTCLASS and OBJECTID are necessary. The first is a string you just have to know, normally you can find out with debugging or analyzing the whole table.

E.g. for a purchase request form (in German "Bestellanforderung") the OBJECTCLASS would be BANF (some kind of SAP short form for the german word for purchase request... ).

And normally, the OBJECTID is just the id or the number or something like that of the desired document / object.

Reading the table with these informations returns no, one or more entries. As you can guess, no entry if no changes has been made. With the field CHANGENR (which is also key field in the table CDHDR and the belonging position table CDPOS) you are able to select easily all belonging positions to the header.

If you would like to read position entries one important thing has to be aware of:

Making a simple SELECT on the table CDPOS does NOT return any value / changed value (fields VALUE_NEW and VALUE_OLD), although seeing these values in the change history log. I don't know how SAP is hiding this information, although it makes truely sense nobody can manipulate this values behind the scenes. If you would like to read this information you have to use the funtion moduls CHANGEDOCUMENT_READ_HEADERS and CHANGEDOCUMENT_READ_POSITIONS.

Hope this was a useful answer to your question...?

Edited by: Alexander Koch on Feb 8, 2008 1:21 PM

[Former Member]

Gert (and everybody else as well),

I tested your recommendations but the problem is still on top.

Your hints have been very useful for understanding the SAP Update Process and I was able to check how the SAP Standard function module is working.

There are several calls of function modules of the type "booking module" and with the options "immediately" or "time delayed".

But also, after all essential function moduls there is a COMMIT WORK.

To be sure this COMMIT really works I even tested with an COMMIT WORK AND WAIT before calling our function module. This and several other trials didn't solve our problem.

Therefore, the next step should be Patrick's proposal. I'm not sure if there is enough time left trying that but for sure, I will let you know.

Kind regards,

Alex

[KKilhavn]

I am shocked....

1) Don't update change documents.

2) Back to the issue at hand: why is the release performed by WF-BATCH instead of being executed by the actual release agent? I have seen exactly the same process that you describe, but all that was needed to avoid it was to declare the method which performs the release in background as dialog method, then it can be executed by the correct agent in the first place and you won't need to start messing with change documents.

3) If you still want to update a change document, see 1) again

4) If you still want to update a change document, go to extreme lengths to ensure you identify the correct CDHDR entry. Pass as much information as you can so you can as a minimum limit your change document header search to a certain date and time range. Do not rely on the "if nothing found no change has taken place" strategy. Your program should KNOW if something has been changed.

[Former Member]

Hi Alex & Gert,

thanks to Gert for this explorative explanations, and the hint to use a terminating event ( BUS2105.Released ) suits me personally better than the COMMIT-WORK-AND-WAIT option.

However, I can offer another approach to bring in the designated user in the first place, not updating the entry afterwards:

Encapsulate the method call to BAPI_REQUISITION_RELEASE by a prelude and export the .. let's say RELEASE_USER to memory:

EXPORT Z_release_user TO MEMORY ID 'ZRELEASE_USER'.

...

Then call the BAPI_REQUISITION_RELEASE (or the object method BUS2105.Release) normally.

Create in implicit Enhancement Point in form routine

Source: FM06BCDC Form: CD_CALL_BANF // Implementation Coding:

   IF UPD_EBAN = 'U'.
      DATA: z_release_user       TYPE sy-uname.
      IMPORT z_release_user FROM MEMORY ID 'ZRELEASE_USER'.
      IF sy-subrc = 0.
         IF NOT z_release_user IS INITIAL.
            username = z_release_user.
         ENDIF.
         CLEAR z_release_user.
         EXPORT z_release_user TO MEMORY-ID 'ZRELEASE_USER'.   "cleanup
      ENDIF.
   ENDIF.  "check on update requisition only

Enjoy,

Florin