cancel
Showing results for 
Search instead for 
Did you mean: 

WF Transport

Former Member
0 Kudos

I would have a small question. I am sure aou have more experience in this. I have to transport (via transport requests) few quite complex workflows from one system to another. I know I have to enter u201CPDWSu201Dfor wrkflows and u201CPDTSu201D for tasks within, u201CPDACu201D for rules, u201CFUGRu201D for function grups and u201DDEVCu201D , business object types

. But I am affraid this is not enought(or?). I wander about customizing table contents (how to find it.. are the necessary) like:

PDST

HRITABNR

HRP1000

HRP1002

HRP1201

HRP1210

HRP1211

HRP1212

HRP1214

HRP1216

HRP1217

HRT1002

HRT1210

HRT1211

HRT1212

HRT1214

PLOGI

PDWS

HRITABNR

HRP1000

HRP1205

HRP1210

HRP1211

HRP1216

HRT1210

HRT1211

PLOGI

SWD_BINDEF

SWD_CONDEF

SWD_EXPR

SWD_HEADER

SWD_METHOD

SWD_MLINES

SWD_MNODES

SWD_STEPS

SWD_TEXT

SWD_WFCONT

SWD_WFCTXT

Is there something else mprtant. Thank you very very much

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Thank you for your answer.(I assigned points).

I never transported WF from source system of one version(4.7x2 ) to target system (ECC6.0) .

It is a little delicate issue as I can not investigate (play with it) as I have even no authorisation to release requests nor acces to OS(and import reqs on other system).

I thoroughly went through the workflows and entered all WS

u201CPDWSu201D for workflows and u201CPDTSu201D for tasks within, u201CPDACu201D for rules, u201CFUGRu201D for function grups(I checked not standard z-functions within methods and its Function groups) and u201DDEVCu201D , business object types u201CSOBJu201D. (however the system did not allow me to enter PROG e.g. ZBUS2081)

The triggering events and agents I plan to customize on target system(do you see a problem here). I think this are the content of u201CR3TR TDAT PDSTu201D

I base my suspition of what has to be entered on transport req from ECC6->ECC6 of an other less complex workflow.

In this case CRM is not involved.

In this case (opposite from the last mentioned one) some entries e.g table contents of TOJTD and SWOTICE (some BAPI entries). e.g.:

BAPIRET2

BAPI_INCINV_CHNG_ADDRDATA

BAPI_INCINV_CHNG_ADDRDATAX

BAPI_INCINV_CHNG_HEADER

BAPI_INCINV_CHNG_HEADERX

BAPI_INCINV_CHNG_TABLES

BAPI_INCINV_CREATE_ACCOUNT

BAPI_INCINV_CREATE_ADDRESSDATA

BAPI_INCINV_CREATE_GL_ACCOUNT

BAPI_INCINV_CREATE_HEADER

BAPI_INCINV_CREATE_ITEM

BAPI_INCINV_CREATE_MATERIAL

BAPI_INCINV_CREATE_TAX

BAPI_INCINV_CREATE_VENDORSPLIT

BAPI_INCINV_CREATE_WITHTAX

BAPI_INCINV_DETAIL_ACCOUNT

BAPI_INCINV_DETAIL_ADDRESSDATA

BAPI_INCINV_DETAIL_GL_ACCOUNT

BAPI_INCINV_DETAIL_HEADER

BAPI_INCINV_DETAIL_ITEM

BAPI_INCINV_DETAIL_MATERIAL

BAPI_INCINV_DETAIL_TAX

BAPI_INCINV_DETAIL_VENDORSPLIT

BAPI_INCINV_DETAIL_WITHTAX

BAPI_INCINV_DOC_DATE_RA

BAPI_INCINV_ENTRY_DATE_RA

BAPI_INCINV_FLD

BAPI_INCINV_GETLIST_HEADER

BAPI_INCINV_IV_STATUS_RA

BAPI_INCINV_PERSON_EXT_RA

BAPI_INCINV_PSTNG_DATE_RA

BAPI_INCINV_SAVE_HEADER_BACKGR

BAPI_INCINV_SELECT_BILL_LADING

BAPI_INCINV_SELECT_DELIVERY

BAPI_INCINV_SELECT_PLANT

BAPI_INCINV_SELECT_PO

BAPI_INCINV_SELECT_SERVICE

BAPI_INCINV_VENDOR_RA

Do you know what that means?

Unfortunately I can not ask developper to reactivate orig. workflow again and enter it in new request.

On the other hand fortunately we customer knows how to test WF

Thank you for any additional idea.

pokrakam
Active Contributor
0 Kudos

Hello Tina,

Sounds like you have quite a job to do. Although if I have understood this correctly, you want to transport workflows from a 4.7 system to an ECC 6 system?

If this is the case, I'm afraid I've got bad news: it's not going to work or you will have a lot of trouble getting it to work. The versions are different (you even skipped one major version), SAP even use different tables in some areas of ECC6.

What I would normally suggest is to transport all the development objects (ABAP reports, business objects and function modules), and then rebuild the workflow in the target system. If you have an existing system to work from and you can copy and paste between sessions then it is not as big a job as it sounds and would probably save you a lot of headaches.

In answer to your earlier questions though, you do not need to transport any of the table in trees you mentioned. As Rob already suggested, the HR tables are transported when you transport an object type PDTS. The others should not need to be transported, these are set up in each system when you perform the workflow customising using SWU3.

Cheers,

Mike

former_member186746
Active Contributor
0 Kudos

It's very difficult to tell what objects lies beneath a workflow template.

Because a workflow uses steps, which uses tasks, which uses methods (of either classes or business objects), which in turn can use programs, function modules, transaction, other methods etc, not to mention you can also include another complex workflow as step in the workflow template

Then there's the issue of events, which can be triggered through transactions SWE2, NACE, SCDO, SWEHR1, SWEHR2, and SWHR3,

I don't think that's all, because in CRM for example you can trigger an event, or workflow through actions

And then there's the issue of manipulating events

Check function modules in SWE2, conditions in SWB_COND, conditions on the event itself with SWEINST

And then there's also the issue of agent assignment, which can use rules (PFAC) for example

I think the easiest would be to get the workflowdeveloper involved. Change the mandant setting in the source system to record changes and then let the WF-developer activate every part of which he/she thinks is needed for the target system.

You could in the end use incremental techniques to find out if you're missing something, but then you have to have someone who's good at testing.

Kind regards, Rob Dielemans