There are many manuals for the workflow system setup, and it’s relatively simple using SWU3 to basically set up the system. I mean how many other modules you know have a screen called automatic customizing? there a few other things to set up after you do finish with SWU3.
Apparently there is a feature of the IDOC management enabling it to start a workflow task whenever an IDOC fails to be received or sent by the system, this option is by default active. there are a few problems with this:
- Usually the people running the IDOCs don’t know it’s there and waiting in their workflow inbox. they mainly use WE02 to monitor their IDOCs. which causes their workflow inbox to overflow/
- IDOCs tend to fail not one by one but in large number when running initial tests on them, and some time even in production due to an unexpected error, I don’t think anyone can analyze anything useful when seeing thousands of workflow tasks in this inbox…
- Whomever did this initial definition did so without using event linkage but directly in some cases.
So I highly recommend you disable this option as soon as possible.
You need to:
- Disable all event linkages form IDOCs in SWE2.
- Disable the tasks starting without event linkage via WE46.
see also note 2031151 – ‘How to enable/ disable idoc tasks’
Mails going out of the system:
The basis team manuals and some workflow ones state the system should send mails to all addresses, this is done by writing * at the allowed recipients addresses in transaction SCOT. This is true only for production systems! the development and QA system should be limited to only specific addresses. since you will probably run test runs of the extended notification mails is these system. you don’t want to explain to the CEO why did he receive mails asking for his/hers approval of non existing documents or simply to spam the QA teams with unnecessary emails.
But you might still want to send mails out of QA systems, well there are two ways of doing so safely:
- You can see the mails content and the recipients addresses in transaction SOST. they will be marked as failed. but this is only because you blocked the receiving address.
- You can open specific addresses in SCOT for yourself or QA teams testing processes with mails (workflow or others).
- Always set the mail priority of categories in the extended notifications to no higher them medium in QA systems. since high priority ones are sent immediately, without waiting to the sap connect job. This might give you a few minutes to stop unwanted mails from been sent.
You are going to need to give all users a few authorizations for:
Transaction SWNWIEX – used for calling not decision workflow tasks from the universal worklist.
Transaction SWO_ASYNC – used for pressing links in the workflow business workplace.
Authorization object PLOG – with AC (workflow rule) in the object type, 1001,1000 in the infotype and DISP in actions fields (* in the rest). this is needed since the next approver is calculated with the current ones auth’s so without this the workflow rules will return wrong results.
Parameter ID ‘SD_SWU_ACTIVE’ with value ‘X’ – display the GOS from sales transactions
Set the TRSP/CORR setting in transaction OOCR to ‘X’. If not set, you will be asked to create a transport every time you create a responsibility in OOCU_RESP, or not be able to do so at all if you are maintaining the responsibility in QA or production systems since transports are not allowed in those systems.