on 06-07-2008 1:49 AM
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
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
80 | |
24 | |
11 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.