05 b 01workflowcustomizing

Editor's Notes

• #6: A number of system settings and activities, which are client-dependent, need to be made for SAP Business Workflow. Online documentation and help can be invoked to describe each customizing task and its function relative to the SAP Business Workflow environment. The activity which is performed here allows you to maintain SAP business workflow standard settings at the ”touch of a button” ( Automatic Customizing ). Customizing for SAP Business Workflow is also checked to see whether it is complete in regards to other important settings which need to be made Afterwards an initial ”verification workflow” can be started to check settings. Automatic Customizing does not include maintenance of the organizational plan nor task-specific customizing such as the assignment between tasks and possible agents.
• #7: The logical RFC destination ”WORKFLOW_LOCAL_xxx” is created automatically, if this logical destination did not yet exist. The user WF-BATCH is requested including password. WF-BATCH has to be created in the current client with the user type BACKGROUND for a background user. Execute the function ”Test RFC destination”. The system tries to log on to the logical destination with the user specified. If there are password problems, logon is not successful (despite the green check mark in the result list). A dialog box to this effect is displayed. Maintain the RFC destination again by double-clicking on the green check mark before the entry ”Workflow RFC destination configured completely.” The workflow runtime system always carries out ist tFRC calls on the logical destination WORKFLOW_LOCAL_<Clnt>. Clnt stands for the 3-digit number of the client. The workflow runtime system only operates with one client. By assigning a name to the logical destination, the system-wide uniqueness of the logical destination is ensured. There is generally no logical destination for the tRFC calls of the workflow system.
• #8: Create a user with the name WF-BATCH, via the user administration function (transaction SU01). Create this user with the user type “background” Assign this user the authorization profiles “SAP_ALL” and “SAP_NEW” Maintain the user address for this user. You need to maintain a logical destination in each client of your system. When logging on to supply the user and password to the Workflow RFC destination (transaction SWUB), select ”Synchronize password” to ensure that the RFC password is automatically copied to the user master record if the password was changed.
• #9: Workflow administrator: Person responsible for the technical side of the workflow definition (system administrator). A workflow administrator must be available for every workflow definition and should be competent, in particular to correct errors in workflows. The workflow administrator is notified automatically of such errors during the runtime execution of workflow definitions. Further notes: Every workflow can have an administrator of it‘s own.. The administrator of a single workflow is defined in the basic data (responsibilities) of the workflow. Decision task as default for user decision: Task which is executed when the user should make a decision. When you create a step of type ‚user decision‘ in a workflow definition, the task entered here is copied to the workflow definition. If you change the entry here, all workflow definitions with user decisions created in the future will be affected. The ‚Generic decision task‘ is ad task supplied by SAP. You can create customer specific tasks. The must refer to method ‚process‘ of object type ‚decision‘. The task must be a ‚general task‘.
• #10: As of Release 4.5 user decisions are only created as full screens. Old workflows still have user decisions as dialog boxes. Advantages of full screen user decisions: The user decision can hide a secondary method, such as object display or ArchiveLink viewer, but can be pushed aside. This was not possible with presentation as a dialog box. Can be sized Attachments are displayed and can be added interactively on the user decision screen.
• #11: In this step, you specify the plan version in which you want to maintain your data. In other words, the active plan version. Set an active plan version. The active plan version is set to ”01,” provided an active plan version has not been maintained. Careful consideration is necessary when deciding which is to be the active plan version for the following reasons: For the purposes of integration, the active plan version in all PD modules is simultaneously the integration plan version. Thus, it is not necessary to set a new plan version each time you implement a new application component. Enter the plan version you wish to use as the active one both for the different PD modules and for integration purposes in the field ”value of semantic abbreviation” of the parameter group ”PLOGI PLOGI”
• #12: Deadline monitoring of work items on an individual basis is performed by a background job that must be scheduled once when the system is started. This background job plans itself each time for the next deadline to be monitored. Scheduling can be carried out via (transaction SWWB). Permanent deadline monitoring of work items, as opposed to monitoring on an individual basis, means that the background job scheduled is called periodically at intervals defined in minutes and checks whether deadlines have been exceeded since it was last called. Carry out the activity for scheduling permanent deadline monitoring (transaction SWWA), in each client of your production system if applicable. Recommendation: Only select permanent deadline monitoring if there are several deadlines to be monitored per minute. This customizing activity must be carried out if deadline monitoring is to be possible in SAP Business Workflow.
• #13: With this activity, you schedule monitoring and special handling for background work items that could not initially be executed because of a temporary error in the underlying object method. These background work items are then restarted automatically. Monitoring is deactivated in the standard version. To activate monitoring of work items in error the following activities will need to be done: Carry out the customizing activity which will invoke (transaction SWWD). Specify whether monitoring should be carried out. Specify the interval between two monitoring runs. Specify after how many attempts the background work item should finally be set to status ”error” Further notes: Carry out the customizing activity again, in each client of your production system if applicable. If monitoring is not activated or the total number of attempts is reached, the work item takes on status ”error” finally. In this status, a work item can be found using the selection report, and the error can be analyzed.
• #14: The start of the verification Workflow step will test the customizing efforts carried out in previous steps by testing some of the basic functionality during execution in the Workflow runtime environment. A work item will be sent to the initiating user of the verification task which will test the sending of both a work item to be executed in the form of a ”User Decision” and a notification sent to the users workplace. During the execution of the ”User Decision” task several functions at the task execution level can be tested, for example: an attachment can be either displayed or created in addition to other functions applicable at the task level via the business workplace.
• #15: The standard objects, e.g. roles, tasks, workflows are created with the prefix of the the entry for system and client.
• #16: The personal workflow settings enable you to adapt the system to suit your users. This is the technical conversion of the concept of user categories. User view with ActiveX (32-bit) User view of the workflow log, which does not contain any technical information. This view uses ActiveX controls and is therefore only available on 32-bit platforms. User view without ActiveX User view of the workflow log, which does not contain any technical information. This view uses the hierarchical list presentation of the ABAP list viewer (ALV). Technical view In addition to the semantically fundamental information, the technical view of the workflow log also shows technical numbers and texts, which may not be available in the logon language of the user. The technical view is intended primarily for system administrators. The table SWL_SYSTEM is used to preset personal workflow settings on a system-wide basis. Important: If a user has already maintained personal workflow settings, these are not overwritten by new entries in this table. Recommendation: If you want to make settings that differ from SAP’s settings, you should do this when setting up your system before users work with it.
• #17: Here you can make settings to adapt the display tools (work item display and workflow log) of the runtime system to your requirements. Other settings Display work item texts in logon language All work item texts are always displayed in the logon language in the user’s integrated inbox. If the logon language of the user is different from the language in which the work item was initially created, additional database accesses are required, which can delay the construction of the integrated inbox to some degree. Enable multiple forwarding of work items The work item can be forwarded to several agents (organizational unit, job, position, user, etc.) (Double)-clicking on an object displays the object in the same window In the work item display, you can select an object to display. This object is then displayed in the window of the current session and replaces the work item display. When you exit the display of the object, you return to the work item display. If you do not select the indicator, a new session is opened to display the object.