Saving Workflow log to a Z table

[ramesh_ananthaiah]

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.

[I042439 · Accepted solution]

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

[ramesh_ananthaiah]

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.

[ramesh_ananthaiah]

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.

[paul_bakker2]

Hi,

My standard response (to requirements like that) is: if the report generates such a large spool file, here is no way any human will be able to digest it all. Business users usually just want a brief summary and maybe a list of exceptions.

I think it would be best to make it an online report (using BAPIs / hitting standard tables) that users can run themselves over suitably small ranges. Then tweak the indexes to make sure it runs fast. Give them a link to the workflow log on each report line so they can fetch more detail if they want to.

But I know - if you're new to the project sometimes you just have to do what they tell you..

Snowing already..?

cheers

Paul

[pokrakam]

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

[former_member186746]

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

[former_member185167]

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

Problem solved!

[Former Member]

@ 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

[Former Member]

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

I am not sure if storing the data of the log history would help? If it is not available in the log, why would it be available in the Z-table (that is based on the log)?

Even if the data would in some way get stored into the Z-table, I would still say that the approach is wrong. Why to store all history data of all workflows, if you just need it for few tasks? There are many alternative and better solutions: using some kind of workflow exit implementation (store decision data in Z-table), etc. And if you have the decision data in a container element, why wouldn't you read it from there? SAP_WAPI_READ_CONTAINER.

Regards,

Karri

[Former Member]

Hi Karri,

     I agree with you completely. I also strongly believe in not having a Z table.

But as per the scenario given above, decision will not be captured in SAP standard log as all step outcome will be like 'Processing complete'.

So in case you need to maintain a abridged log let say only

UserID, User decision, User Comment, Date and time on the BO Web UI for business users who are only interested with Dialog type WI and above fields, it would be easier to update this from the event handler method on webform.

Just a scenario. DOn't recommend implementing it.

That's why suggested the terminating event one

[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

[I042439]

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

[Former Member]

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

[paul_bakker2]

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