Transaction SWUD

     SWUD is the diagnosis transaction. This will guide you through the fault  finding process. The check-list order is determined dynamically
     according to:

 a) your workflow definition and

 b) the statistics of the most common mistakes made when

creating/activating a workflow.

 The testbed, provides a launchpad for tests to ensure that your workflow definition is rugged enough for the production environment. It also allows you to access the tasks, subflows, object types, delegated object  types and agent assignments directly, without going through the workflow builder first. (Foreground tasks with no agent assignment are marked in red from release 4.5 onwards). This list is also useful as a catalogue of the components of workflow for documentation or transport purposes.

     Click on the “info” icon to read a description of the test being performed.
     Any workflow accessed through this transaction is added to the last-used
     list. The workflow can be recalled at a later date by clicking on the
     reuse icon in the left-hand column of the last-used list.
     The next section describes the transactions called from SWUD. Experts
     may find it easier calling them directly.

     Secondary Diagnosis Transactions

         o  Transaction SWU3: Verify Workflow Customizing.
            In this transaction the most important basic customizing for
            workflow is checked. If you find any errors here, read the
            documentation for the error. If your system is BBP or CRM, see
            note 60801.

         o  Transaction SWEL: Event Log.
            Note: Before you can use the event log, you must make sure it is
            activated. You check this in transaction SWELS. If you are not
            sure whether or not it is active, just deactivate and activate
            the event log once.
            WARNING: An activated event log can lead to bad performance, and
            must not be activated constantly in a productive system.

         o  Transaction SWE2: Event type linkage
            A workflow is usually started or triggered by an EVENT so it is
            important to make sure that an event occurrs. In the event log
            you can see the event and its business object type.
            If an event has been successfully created, it is important to
            check if there is a receiver type for this event. The receiver
            type is the workflow that has been triggered by the event.
            The coupling between an event and the receiver can be maintained
            in trans. SWE2.

         o  Transaction SWU0: Event simulation
            If you have found NO receiver type in the event log, then you
            should check transaction SWU0, Simulate Events.
            In this transaction you can simulate an event. The system will
            check all workflows that could be triggered by the event and
            tells you whether or not they were triggered. Information is
            displayed for the workflows that were not triggered successfully.

         o  Transaction SWI1: Work item list
            If a workflow was been correctly triggered and started at least
            one WORK ITEM should be created. You can view the work items in
            transaction SWI1, Work Item Selection.
            The easiest way for the selection is just to go into this
            transaction after you have checked the event log. By default all
            the work items of the last hour will be displayed.
            You will find in this transaction the work item number, the
            status of the work item and the workflow task that has created
            the work item. Furthermore, (in the technical workitem display)
            you can have a look at the container by selecting a work item and
            using the menu GOTO -> CONTAINER. To display the work item
            details double click on the item. From the details you can see
            the selected/ possible/excluded agents for this work item by
            using the menu GOTO -> AGENT -> SELECTED/POSSIBLE/EXCLUDED
            AGENTS.
            When the status of the work item shows an error you should have a
            look at the workflow log using the menu EDIT -> DISPLAY WORKFLOW
            LOG. Here you can see errors that have occurred.

         o  Transaction PFTC/SWDD: Task editor/Workflow Builder
            If you want to have a look at the definition of the workflow you
            can use transaction PFTC, Maintain Tasks.
            The button WORKFLOW BUILDER brings you to a graphical display of
            the workflow structure which is fairly easy to read and
            understand. On the tabstrip TRIGGERING EVENTS you can check if
            the triggering is activated or not and deactivate/activate it by
            clicking on the icon in front of the event.

         o  Transaction OOCU: Customizing overview
            To check if the relevant tasks are activated and users are
                                                           

            assigned, you can use transaction OOCU; Task Customizing
            Overview.
            In this transaction all the tasks are sorted by the application
            components and are thus easy to find. Note that if you have
            almost no entries in this transaction, you should execute  the
            report RS_APPL_REFRESH in transaction SE38.

         o  Transaction SWUE/SWUS: Event/workflow trigger
            If you have activated a user exit, e.g. for the role
            determination, and you have problems with that, you most probably
            have to debug the workflow. This can be done using the
            transaction SWUS or SWUE.
            With SWUE you can create an event. After you entered object type
            and event you have to fill the event parameters and the key for a
            specific object. If you want to debug the workflow you have to
            set the flag TRIGGER RECIEVER FM SYNCHR. If you have set a break
            point in your user exit or in any other function module of the
            workflow the system will stop at this break point and you can
            start analyzing.
            The second possibility to debug a workflow is to use the
            transaction SWUS, the workflow test environment. In this
            transaction you have to enter the workflow task and fill the
            input data. Please use the F4-help to fill the input data. Here
            again you have to set a break point in your user exit or in any
            other function module of the workflow and then the system will
            stop there.
     Summary of the manual alternative to SWUD
     Now that you have a better understanding of how to use these
     transactions, you can follow the steps below to quickly analyze your
     workflow problems:

     1.  Go to transaction SWU3 and check if everything is okay. If it is
         not, please fix it before you proceed.

     2.  Go to transaction SWEL and check if an event is created. If not,
         check in transaction SWELS if the event log is activated.

         o  If you see an event but no workflow is triggered, proceed with
            step 3.

         o  If you see an event and a workflow is triggered, but the status
            of the triggering shows an error, proceed with step 3.

         o  If you see an event and a workflow is triggered and there is no
            error, proceed with step 4.

         o  If the event log is activated and you do not get any event, open
            up a message using the component of the application to which the
            business object type belongs. From release 20C for creation of
            shopping carts
            the architecture of workflows changed and no events are visible!

     3.  Go to transaction SWU0 and simulate the event. Is the workflow that
         you expect to be triggered visible in the simulation?

         o  If it is not, then check the workflow definition in PFTC. The
            event must be defined as triggering event.
                                                             

         o  If it is, but the event linkage is not activated, go to
            transaction OOCU and activated it.

         o  If it is visible, but it is not activated, go to transaction PFTC
            and activate it.

     4.  Go to transaction SWI1. Search for the work item that belongs to the
         workflow. Check the status of the work item.

         o  If it shows an error, look at the workflow log. Do you see any
            errors? If yes, you can probably find a solution in the SAPNet
            Frontend. (Tips and tricks on how to search for information and
            solutions in the SAPNet Frontend can be found in note 192194.) If
            you do not find any help in the SAPNet Frontend, please open up a
            message with the component BC-BMT-WFM and tell us the number of
            the error message and the name of the workflow.

Unique collection of SAP Business Workflow Interview Questions and Answers those are generally asked during the interview. You must know these concepts and answer before going to interview.

This document help you to organize your knowledge and make it in systematic and presentable form. This document can be use as power in your hand during your interview.

This document cover general question and answers as related to technical and functional side of Business Workflow. This document will also be useful for, if you are working on the project and you need to sound your fundamentals

Some of the related topics are as given below,

SAP Business Workflow Conceptual Document
Configuration Related Questions
Practical/Troubleshooting Related Questions

This document is available for download ! Click Here to know More and Buy Now !

SAP Business Workflow Interview Questions