Skip to Content

Saving Workflow log to a Z table

Hello Friends,

I have requirement to save workflow log to a Z table. After lot of analysis we found a enhancement spot in the FM "SWW_WI_LOG_WRITE_SUCCESS" and wrote a logic here to update the Z table.

The entire logic and whole functionality is working fine even when workflow is triggered from ECC SAP inbox and also from NWBC - Portal.

But the problem I am facing is delay - the workflow status of the work item are 1 step behind in the ZTABLE compare to what is stored standard SAP log. If if process the work item to next step then the previous status gets updated.

In Std Work item ID : 2380284 - > Completed, But In Z table the same is 2380284 -> Ready

2380285 - > Completed, But In Z table the same is 2380285 - > Ready

The updates in Z tables are 1 step behind. Please let me know any suggestion to improve this. I have written commit work after the z table is modified.

Please help me.

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

9 Answers

  • Best Answer
    Posted on Nov 17, 2014 at 05:00 AM

    Hi Ramesh

    Maybe now is the time to don the consultant hat and leave the developer hat.

    Advise the team to look at the future!

    Okay - they need faster performance, you may still keep the Z table, but populate the container specific data from the Program Exits in the workflow rather than enhancement spots.

    Advantages:

    1) You will be tracking only the required items and not reading every workflow and every work item and then using IF conditions to filter out - will also avoid too large a size of the custom table

    2) Workflow container is already available in the Program Exits , so you would avoid reading the WF Log from DB

    3) Program Exits are designed for the same purpose as yours - State Change information gathering

    4) Populate all details in the Z table and a small select on a single table will obviously increase performance

    Regards,

    Modak


    Add a comment
    10|10000 characters needed characters exceeded

  • Posted on Nov 14, 2014 at 12:55 AM

    Hi,

    Can you please explain why you are writing the workflow log to a Z table? Why store the same information in two places - inconsistencies between them are inevitable.

    I'm sure there'a good reason.. but I can't think of one right now.🤪

    cheers

    Paul

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Nov 14, 2014 at 03:10 AM

    I would also question why are you trying to store the workflow log into a Z-table? There should be a really good reason for this, and even then it is most probably wrong.

    1) Why do you need to have same data in two places?

    2) Depending on the implemented workflow processes, the workflow log table(s) can be really big. Why would you want to replicate even part of this data? Many times the question of deleting & archiving the work items (and the log data) appears sooner or later.

    Clearly the place of the custom code is not right, if it does not store correct data into the Z-table. Did you debug this? Are you getting right data in your enhancement spot?

    Once you explain the background of this requirement, someone might give you a better solution, and you could forget the whole enhancement spot solution altogether.

    Kind regards,

    Karri

    Add a comment
    10|10000 characters needed characters exceeded

  • Posted on Nov 14, 2014 at 04:31 AM

    I Agree with Paul and Karri - 101%

    Please do let us know the "complex" business requirement to do this... maybe, there is an easier alternate! Maybe Program exits can help you to track only the 'required' workitems and not ALL! Maybe we are over engineering! Look at the future - people maintaining this 'Z' development will always be pulling off their hair!

    But then, Maybe, there is some requirement which we cannot think of and which lead you to this design!

    Regards,

    Modak

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Nov 14, 2014 at 06:31 AM

    @ Paul, Karri, Modak - I can think of a scenario (correct me if I'm wrong)

    Scenario - You have a web form (lets say Webdynpro based) where you are handling user decision.

    User one - He can approve, reject

    User two - He can acknowledge

    User three - He can approve, reject, cancel, rework, escalate

    For all the 3 scenarios, same task is used, (changing parameters on task to method binding to vary web from dynamically). The task has just one outcome. From the web form, at a button click (approve, rej etc) we are completing the WI using FM and passing the user decision to a WF container. This container value is checked to determine the next path of WF.

    In case like this, the user decision will not be captured in standard log because the activity has just one outcome always i.e. 'Processing complete'.

    @ Ramesh - I'll go with Paul, Karri and Modak on this. Avoid Ztable for WF log. If you have a scenario like I wrote above, here's what you can do.

    Create events in your BO or ABAP class which are related to user decision (one for every button on web form). Link all the events as terminating events for your task.

    Now where ever you use this task (for user 1, 2 and 3 as per above example), only activate the required outcomes on the activity step.

    Plus in case you are using ABAP class I would suggest to go for an async task in case you are using webdynpro.

    Thanks,

    Aniket

    Add a comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      There are definitely times when there might be a need for implementing some sort of Z-table logging solution. I agree completely with that. If I remember correctly there is nice SCN blog (or wiki or whatever) by Pavan, in which he describes a simple example how to implement a Z-table logging with workflow exit. Just an example.

      If you have access to the actual workflow application (web UI or whatever), then it makes a lot of sense to insert the possible logging functionality there (and not store the data into workflow containers, logs or whatever).

      If you take a look to the original question, it was about storing the whole workflow log into a Z-table. So, we are talking about a different thing here.

      Regards,

      Karri

  • Posted on Nov 14, 2014 at 07:40 AM

    Workflow logs are already stored in tables. You access them with SAP_WAPI fms.

    Problem solved!

    Add a comment
    10|10000 characters needed characters exceeded

  • Posted on Nov 14, 2014 at 09:58 AM

    Hi,

    What is the functional /business reasoning behind this requirement?

    What usually happens in workflow is that there is an additional requirement to store specific data in a log. Mostly related to approvals and previews and agents and such.

    Yours is weird and I can't see what the added value is of this development.

    If you want to keep following this path then make sure that the tables that you are using are incorporated in archiving object WORKITEM the logging tables can be huge and if not maintained properly it will mess up the system.

    Kind regards, Rob Dielemans

    Add a comment
    10|10000 characters needed characters exceeded

  • Posted on Nov 14, 2014 at 08:05 PM

    Hello Friends,

    I am sorry took a little while to reply.. Stuck in hefty pacific snow outburst on NE coast and have been driving me crazy since last night...

    Actually I joined the team late by that time the entire design was out and everything was in place to read the logs from Z table log. Just a pending task was assigned to me to update the table via enhancement spot.

    The reason of Z table is, There is already a report program specifically designed to our customer needs to display the approval workflow log based on every status it is changed reading data via standard SAP tables SWW_WI2OBJ ( key field - GUID ) and then call FM - SWP_WORKFLOW_LOG_READ.

    There is some thing called CR's that are created and that are linked to work items from MDG and then they flow to ECC .. Like creating of Material in MDG and then that flows to ECC..So workflow exists at both MDG and ECC sides.

    While we use this Z report - using standard SAP workflow tables for logs (mentioned above).. there is huge performance issue and it is getting timed out if we read the data for more than 2 months..

    1) I suggested to run the report in back ground but was denied as the end user may not have access to spool and SM37 etc...

    2) I suggested to email the spool to respective user .. but the spool size is ove 25 MB to 50 MB which makes impossible to attach the same in mail.

    Hence they create a z table with multiple primary keys, then access becomes easy and they do not have to hit the standard SAP tables every time the report is run. Several selections screens are provided to extract the report.

    Structure of Key fields of the Z tables - so querying will be easy..

    MANDT MANDT CLNT 3 0 Client CR USMD_CREQUEST NUMC 12 0 Change Request WI_ID SWW_WIID NUMC 12 0 Work item ID WI_DAT SWW_CD DATS 8 0 Creation Date of Work Item WI_TIM SWW_CT TIMS 6 0 Creation Time of Work Item

    Hope this clarifies.

    Also logging to Z tables only for certain type os of workflow ending 13, 17, 21 .

    Workflow type = W/F.

    Please let me know if this makes sense.

    Add a comment
    10|10000 characters needed characters exceeded

    • Hello Ramesh,

      Ramesh Ananthaiah wrote:

      ...

      The reason of Z table is, There is already a report program specifically designed to our customer needs to display the approval workflow log based on every status it is changed reading data via standard SAP tables SWW_WI2OBJ ( key field - GUID ) and then call FM - SWP_WORKFLOW_LOG_READ.

      ...

      When I read that it is immediately obvious that the solution is - how shall we say it kindly - less than optimal and doesn't make full use of features offered by SAP Workflow. A little knowledge can go a long way, and there's even a nice book out there that has some useful information about workflow (and supports good causes too!).

      As for the argument that the report cannot run in background because the user may not have access to see their own jobs... well that surely is justification for butchering the system!

      For one thing, with a little bit of thought one can make the WF log quite user friendly - which is often neglected. So a custom report with a drilldown to display the WF log makes it quite easy to see who did what and when. Performance can also be managed by optimizing table accesses.

      If you absolutely have to go down this route, I would highly recommend using the SAP-provided workflow exits that get called at every status change rather than enhancements. Just implement the interface in a class (there are good examples provided by SAP) and plug it into the relevant steps in your workflow builder (Exits tab).

      Regards,

      Mike

  • Posted on Dec 10, 2014 at 06:35 PM

    Thanks you guys for your help on this finally, we wrote the logic to update the Z table in Program Exits in the workflow.

    That worked very well and users are trilled to see the new report performance..

    Thank you.

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.