Question Re: database table for Workflow Container values in Technology Q&A

database table for Workflow Container values

bhakti2 — Tue, 28 Feb 2012 06:40:36 GMT

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

Re: database table for Workflow Container values

Former Member — Tue, 28 Feb 2012 07:09:47 GMT

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

Re: database table for Workflow Container values

bhakti2 — Tue, 28 Feb 2012 08:37:48 GMT

thank you for the reponse

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

thanks

Re: database table for Workflow Container values

Former Member — Wed, 29 Feb 2012 22:08:45 GMT

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

Re: database table for Workflow Container values

bhakti2 — Thu, 01 Mar 2012 03:45:55 GMT

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

Re: database table for Workflow Container values

Former Member — Thu, 01 Mar 2012 05:43:07 GMT

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

Re: database table for Workflow Container values

Former Member — Thu, 01 Mar 2012 05:45:31 GMT

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

Re: database table for Workflow Container values

bhakti2 — Thu, 01 Mar 2012 05:50:54 GMT

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

Re: database table for Workflow Container values

Former Member — Thu, 01 Mar 2012 06:54:26 GMT

>- 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

Re: database table for Workflow Container values

bhakti2 — Thu, 01 Mar 2012 07:32:49 GMT

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

Re: database table for Workflow Container values

Former Member — Thu, 01 Mar 2012 07:36:00 GMT

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

Re: database table for Workflow Container values

bhakti2 — Thu, 01 Mar 2012 07:41:16 GMT

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

Re: database table for Workflow Container values

Former Member — Thu, 01 Mar 2012 07:59:01 GMT

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

Re: database table for Workflow Container values

bhakti2 — Thu, 01 Mar 2012 08:20:10 GMT

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

Re: database table for Workflow Container values

Former Member — Fri, 02 Mar 2012 22:27:33 GMT

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

Re: database table for Workflow Container values

Former Member — Mon, 05 Mar 2012 02:25:34 GMT

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

Re: database table for Workflow Container values

bhakti2 — Wed, 07 Mar 2012 06:28:52 GMT

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.

Re: database table for Workflow Container values

Former Member — Wed, 07 Mar 2012 07:29:42 GMT

>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

Re: database table for Workflow Container values

Former Member — Wed, 07 Mar 2012 07:59:08 GMT

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

Re: database table for Workflow Container values

bhakti2 — Wed, 07 Mar 2012 08:22:59 GMT

 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