database table for Workflow Container values

[bhakti2]

hi,

I am on SAP ECC 6.0

I am trying to find workflow id number starting from document number

I try to find database table which has containe values of the workflow instances so that I can get workflow/workitem instance numbers for the document

this is custom workflow and it is not based on business object type. so checking container values is the onlyway I can get the workflows

but I am not able to find any table for it

I have checked following

SWW_CONT

SWW_CONTOB

SWWVCONTWI

SWXML_CONT

SWJ_CONT

SWJPCONT

SWJSCONT

SWPCMPCONT

SWU_CONT1

SWUOCONT1

almost all the SWCONT tables

Morever I put St05 trace to see all the tables in database operations while triggering the workflow

but the only tables seen here are

SWWHRINDEX

SWD_CONT

SWWWIHEAD

SWWCNTP0

SWWLOGHIST

SWWWIRET

SWWCNTP0 is Workflow Container: XML Database (P0)

but it is XML structure data. so its of new use to query container fields.

is this reason because of any workflow design or system config ?

how to read container values from database tables in such case?

thanks

bhakti

[Former Member · Accepted solution]

Hello,

They are most likely in SWWCNTP0 but they are only readable using function modules, e.g. SAP_WAPI_READ_CONTAINER.

I know, it is annoying. Much easier when they were stored in SWW_CONT.

If the document number is used in the workitem texts (e.g APPROVE: Doc no. xxxxx) then you may be able to get them from SWWWIHEAD.

regards

Rick Bakker

hanabi technology

[Former Member]

I really liked this conversation.

And to add to this, also found the table name I was searching for

Thanks Bhakti, Rick and Karri

[Former Member]

Hi Bhakti,

Please could you advise me how we use Z table in workflow.

My requirement is escalate approval work item to the users supervisor if an approval is not executed after 3 days.

I'm new to workflow so please advise.

Thanks in advance.

Sudheer

[Former Member]

Hello,

Since you are new to Workflow I will offer you some advice:

Do NOT use Z tables with Workflow, unless there is no other option.

For example, in your case you can probably make use of rule AC00000168 to find the line manager.

Please always open a new thread with the specifics of your question, you will get more answers that way.

regards

Rick

[bhakti2]

there is no requirement of ztable

also following wat Rick says

in yr case created a loop

inside that loop keep the approval dialog workitem

put latest end details and bring out a modeled deadline

in the deadline outcome, mark the dialog workitem to obsolete

you will need to activate the obsolete outsome in the dialog step

in the obsolete branch outcome set appropriate counters for looping and changing agents

Message was edited by: Bhakti . (corected for there is 'no' req of ztable

[Joseph_BERTHE1]

Hello,

We have developed a solution to full fill this kind of requirement. It is a powerfull tool which is able to adapt to any kind of business need like searching inside a container and apply actions to workitems.

I can help you if you want, contact me by email.

We can send to you documentation as well.

Kind Regards

Joseph BERTHE

joseph.berthe@renelco.ch

[Former Member]

You cannot advertise for your products here. Please review the rules of engagement: http://scn.sap.com/docs/DOC-19331 where it clearly states: "Do not embed links to ads in blogs, documents, and forum discussions.  The same goes for email solicitations and advertising."

[Former Member]

Hi,

I would actually say that using a Z-table is not that bad idea in this case.

The "mistakes" have already been in the initial workflow design/build phase by not using business object/ABAP class and/or some other better design (saving the data into Z-table at the first place instead of storing it purely in container, etc). Clear separation between the business logic, workflow and data storage is always a good idea.

Regards,

Karri

[bhakti2]

hi Karri and Rick,

- ABAP objects have been used in existing workflow

- also Z tables have been used at various points in the workflow template itself (workflow start, approval , rejection). I am using the same ztables, i havent created now myself. is it the same thing what Karri is talking (saving the data into Z-table at the first place instead of storing it purely in container, etc)

- business object has not been used in the workflow design

- its not possible to introduce business object in the workflow now

- it is not possible to get all the workflows and check one by one. they cudnt be recent invoices, report can be used by anyone, invoice number is on the selection screen.

as a conclusion , it should be followed as a practice to use business object in the workflow design and make use of the attributes and events of the business object for triggering the workflow and other things.

thank you fr yr help

[Former Member]

>- ABAP objects have been used in existing workflow

Then can't you find the workflow ID based with some ABAP object? Transaction SWI6.

Regards,

Karri

[bhakti2]

hi Karri,

no I cant find the workflow instance from SWI6 by giving ABAP class

the reason for this is prob bcoz ABAP class event is not used to trigger the workflow

also abap class is not workflow container

the workflow has been triggered in user exit of std transaction using SAP_WAPI_START_WORKFLOW

abap class has been used to do all the business logic ie the background tasks have methods of this abap class

[Former Member]

So, in other words, the class cannot be instantiated. You cannot make an object from it. No constructor? It is just a collection of static methods... If yes, then you are right - SWI6 will not work.

Regards,

Karri

[bhakti2]

yes. it is just collection of methods. there is no constructor. its just used to do abap coding which might as well could have been done in business object methods by extending it

reason to trigger workflow like that is - there is pop in FV60 confirming whether workflow shud be triggered and only if user clicks yes, the workflow is started

[Former Member]

Hi,

If you are triggering the workflow from FV60, I assume you are having a workflow related to an invoice (BO FIPP). IF yes, and if you know the document ID (=key) during the popup, please try to deliver the FIPP business object instance to the workflow with SAP_WAPI_START_WORKFLOW. Or if you know the key in the workflow, instantiate the FIPP in the beginning of the workflow. Once you have the instance in the workflow, you will see lots of benefits: you can find the workflows easily (=your initial problem), you can drill down to the workflow log from FB03, etc.

Of course if your workflow is not directly related to the invoice document, etc. the above is not important.

Regards,

Karri

[bhakti2]

hi Karri,

this is invoice based workflow. i will try to create FIPP container and populate it at the time of trigger

thank you for the suggestion

i realised FB03 also doesnt show up , neither SWI6 etc

[Former Member]

Hello,

Using SAP_WAPI_START_WORKFLOW (instead of events) - not a good idea.

Not using BOR or classes for important data - not a good idea

Using Z tables for approved statuses etc - not a good idea.

Your workflow developer needs training.

regards

Rick Bakker

hanabi technology

[Former Member]

Hi,

I certainly agree with Rick with certain aspects. Try to use SAP_WAPI_CREATE_EVENT instead of the direct workflow start. If you know the key of the FIPP during the starting, just create a new event (ZCREATED ot whatever) for FIPP and use that to start your workflow. You should be able to do the same stuff with the above mentioned function as you do now with the direct workflow starting. Then you also don't need to figure out how to deliver FIPP object instance to the workflow. Also, events for starting a workflow are much better options in any case.

If you have some Z-table to store some of the data & statuses (or whatever), it would have been a good idea to build a BOR or a (real instance based) ABAP class to encapsulate all functionality related to this Z-table. Anyhow, we don't know anything about your scenario, so your basic design might be just OK.

Regards,

Karri

[bhakti2]

Using SAP_WAPI_START_WORKFLOW (instead of events) - not a good idea.
Not using BOR or classes for important data - not a good idea
Using Z tables for approved statuses etc - not a good idea.

first two points are clear but for the third point , to eliminate the ztables for status, i was trying to think of alternative when Karri suggested following. so does it mean that the status could be updated in the object attributes at various points in workflow ?

build a BOR or a (real instance based) ABAP class to encapsulate all functionality related to this Z-table.

[Former Member]

>so does it mean that the status could be updated in the object attributes at various points in workflow ?

Not really. The object gets its attributes from database => you need to update the database. You always need the logic/code for updating the database.

Your solution is probably OK already. You have a Z-table, and that might be the best solution available. The workflow container is not always the best place to store data. IF you have some business relevant status or whatever data (and there is no table to store this in standard), it might be actually the best idea to store it to Z-table.

Just next time if you have a possibility to develop a custom workflow from scratch, spend few moments to think whether you could build your own instance based WF ABAP class that encapsulates your business logic (for example, when you update the values in Z-table by using a method of the class, this will have an effect in your ABAP class attributes in workflow, etc. - just like FIPP works)

Regards,

Karri

Edited by: Karri Kemppi on Mar 7, 2012 9:30 AM

[Former Member]

Hello,

"first two points are clear but for the third point , to eliminate the ztables for status, i was trying to think of alternative"

What I was referring to was this:

"also Z tables have been used at various points in the workflow template itself (workflow start, approval , rejection)."

Workflow start, approval and rejection can and should be be read from the workflow tables.

Making separate z tables for this is very wrong and unfortunately all too common,

especially amongst ABAP programmers who haven't got much workflow experience.

Having z tables for useful non-workflow-related data is worth considering.

regards

Rick Bakker

hanabi technology

[bhakti2]

 Workflow start, approval and rejection can and should be be read from the workflow tables

which means that we should make out from SWWWIHEAD abt rejection approval status which is quite tedious

and workflow std tables for container elements are also no longer found.

Edited by: B on Mar 7, 2012 1:53 PM

[Former Member]

Hello,

No, it would be done using SAP_WAPI* functions and tedious is the maintenance of Z tables, not writing one-off ABAP programs.

Don't store the same information twice - computer science 101.

regards

Rick Bakker

hanabi technology

[Former Member]

Hi,

I am not sure anymore what is the problem. But I would do the following:

If you now have FIPP instance in the workflow, you should be able to find the work item ID and read the container with SAP_WAPI* functions based on the invoice number. => Standard and good way of development. (Anyhow, make sure that you still can find the data after the invoice has been posted (=the FIPP (parked document) doesn't really exist anymore).

Now, if you can find all the relevant data (Which data do you actually need, can you explain?) in the container, get rid of the Z-table.

If you still have some custom business data that you think should be in a separate table (some data that cannot be found in standard tables (excluding WF container tables)), leave the Z-table.

Regards,

Karri

[bhakti2]

hi Karri,

i need to display an ALV list with list of invoices and whether the workflow is awaiting / approved / rejected for review / approval. and who did the approval / rejection action

so i take invoice numbers from selection screen and then find workflows using the newly created FIPP object in the workflow containre (and populating it at the very first step)

the workflow has two steps - review and approve and so i would query table swwwihead for the parent id of workflow and then based on task number see which is ready status task and fiind if its awaiting approval or rejection

and if these dialog tasks have completed status then i would say that its either rejected or approved based on the subsequent steps.... (this part im stil to put) so primarily it wud be swwwihead table ill use to get the workflow status data

apart from this, several data like amount values, reference document, creation date and whole lot of invoice item and header level data is required which needs to be taken from workflow container so once i have the workflow id number using the newly introduced FIPP businesobject, i shud be able to take it. the business object instance will be there int he system even after the document is posted.

thanks

b

[Former Member]

Hi,

>i need to display an ALV list with list of invoices and whether the workflow is awaiting / approved / rejected for review / approval. and who did the approval / rejection action

This you should be able to read from container now, if you have FIPP instance.

>the workflow has two steps - review and approve and so i would query table swwwihead for the parent id of workflow and then based on task number see which is ready status task and find if its awaiting approval or rejection

Don't do any selects to SWWWIHEAD unless you have some really specific reason. Just use SAP_WAPI* functions. You should be able to get each depended work item etc. easily with the standard functions.

>apart from this, several data like amount values, reference document, creation date and whole lot of invoice item and header level data is required which needs to be taken from workflow container

Why would you read this data from container? This data is in the SAP tables VBKPF, etc. There should be even functions to get all data related to an invoice - try to search for example with READPRELIMINARY* (read preliminary invoice).

In general:

1) if you have invoice number, get all related work items with a SAP_WAPI* function

2) if you have only the top WI ID, use SAP_WAPIDEPEND function to get the depended work items

3) with above function you probably will get also the status of the tasks / work items, so you don't need select in SWWWIHEAD

4) Now you have the "status" and the workflow data for the invoice

5) read the invoice data from standard FI tables (unless there is some specific reason to get it from WF container, and if there is, then I think that you might be having some fundamental problems in your design)

Regards,

Karri

[bhakti2]

hi

I need to read the invoice data from the workflow itself and not the READPRELIMINARY* because the relevant amounts, cost centers, approvers etc have been already determined in the workflow with the required approver determination logic. so it wudnt be good to re-apply the workflow logic in the report to find the actual data. inshort, its not invoice data directly its actualy the workflow data of the invoice.

so ill use the SAP_WAPI* FMs for both status and the data.

i think it wont be wrong to get the data from workflow because - example..... the workflow approval logic is that the line item of highest local currency amount of particular account assignment type, again based on MM or FI workflow needs to be selected . so all of this has been done in the workflow and resultant data is there in the containers.

thanks

[Former Member]

OK. I see.

One last comment: You could consider of of calling the same methods from your report that you are calling from workflow to get the data into container. Of course if your methods were already designed to work with WF container (resulting data structures are certain type etc.), then it doesn't perhaps have much sense. This is just a point of view - I personally usually try to keep reading from container as minimum as possible. Sometimes it is a must to read from container, for example if the latest correct data can only be accessed from container. But let's say the all work items older than one year were deleted/archived, and you want to run your report for old invoices - the container data is not anymore in database, BUT the invoice data still is => your report will work if you read the data from FI tables. I am not saying that this is a relevant problem for your scenario (you probably want to just monitor the current status of workflows/invoices or whatever), but something for you to think about.

Regards,

Karri

[bhakti2]

hi Karri,

all work items older than one year were deleted/archived

and this is basically a workflow report.... so if the workitems were archived then it wouldnt work anyways because the status, approver etc information abt the workflow wont show up. it cud be that this reports used for current data (as its sort of monitoring tool for worklfow) but could you please tell me how can I check archive/deletion settings of the workitems ?

thank you

Edited by: B on Mar 8, 2012 9:27 AM

[Former Member]

Hi,

I think you are all good now. Maybe you learnt something valuable for future projects.

Deletion/archiving - search about SAP data archiving and archiving object WORKITEM. Nothing will be archived automatically, the archiving is a small "project" itself. I wouldn't worry about this now if I was you.

Regards,

Karri

[bhakti2]

the report is on its way already

its the same archiving - it would apply equally well to invoice tables too

thanks for val inputs on the exploration on the subject.

[bhakti2]

thank you for the reponse

solved problemby making entry in z-table at different points in workflow

thanks

[Former Member]

Hello,

Making a Z table is not a good idea when the data is already stored in the workflow log.

regards

Rick Bakker

hanabi technology

[bhakti2]

hi RIck,

i do not have the workflow id number with me

i have invoice number for which i need to find the workflows

busines object has not been used in the wf design so i cant use WAPI funciton modules to get wf instance number from the invoice document number

pl advice.

thank you

[Former Member]

Hello,

If you can still change the workflow then I would add a BOR (or class) which does include the document number.

If not, you could retrieve every instance of that workflow (search on WS..... number) and check the container of each one (using SAP_WAPI*) till you find the document number. Of course, that may be a problem if there is a huge number of them. You could check them in reverse chronological order if recent ones are more likely to be sought, it all depends what this is for.

You're right, making a Z table could be the best thing to do here. But only as a last resort.

regards

Rick Bakker

hanabi technology