Tip When no date is specified, a user's workload is the contents of their workflow inbox. Work items in error will not be shown. The list of work items is grouped according to actual agents and tasks. At the end of the list, the work items and tasks for which no actual user exists are displayed under the header Not reserved by an agent.
While much can be done in the workflow to help improve the business process, simple consider- ations such as checking that all agents have received workflow training, or send- ing e-mail notifications to agents of outstanding work items, or an intranet based FAQ list, can be used to improve the process without needing to change the workflow itself.
The most useful tools for justifying potential improvements are the error overview and performance reports. In particular, frequent failures in determining agents can lead to more robust rules for agent determination, or to tightening of procedures for agent maintenance by human resources and security personnel. Workflow performance reports show tasks that have long wait and process times. If many agents are asking for similar improvements, that in itself may be sufficient justification for changing the workflow.
Prompt error resolution is vital if confidence in both the business process and the workflow are to be maintained. As a workflow administrator, the worst mistake you can make is to fail to plan for failures. The most likely time for failures to occur is immediately after the workflow is acti- vated, or after changes to the workflow are activated.
This is also the most critical time for building confidence in the workflow and the business process. You need to make sure that as a workflow administrator you know how important the pro- cess is, who will be impacted by the failure so you can reassure them that the problem is being handled , what to do and who to contact to make sure any errors are resolved quickly and confidently.
This is particularly true of the very first workflow activated in your organization! Diagnosing the problem 2. Fixing the problem 3. Preventing the problem from happening again A considerable number of tools are provided to help you diagnose errors. These tools range from simple reports to detailed technical traces to complex graphical displays.
These error diagnosis tools are heavily used by workflow developers test- ing their workflows, and as needed by workflow administrators diagnosing errors. Due to the large number and variety of tools, diagnosis is a separate topic in itself that will be covered in chapter 14, Advanced Diagnostics.
If workflow administra- tion is new to you, you may want to get some assistance from your workflow developers in diagnosing errors. Watching a developer solve a workflow problem can be a very effective way to learn how to diagnose workflow errors. However, when a workflow developer diagnoses a problem, they usually just abandon the failed workflow instance, make some changes and start a new work- flow instance.
In a production environment, you do not usually have the luxury of ignoring failed workflow instances. You actually have to fix the problem. So in this chapter the focus is on how to resolve the error once you have diagnosed it, i. For example, the workflow does not take into account incomplete data extracted from legacy systems, or exceptions in object methods are not trapped.
Make sure that people involved in the business process are aware that problems need to be reported promptly. Anecdotal evidence that a process has failed is often very hard to match with the offending work item. So encourage people to report object keys e.
As stated earlier, pro- cesses that have been put into workflows are nearly always critical, essential or high-volume. So if an error does occur you need to act promptly and fix it fast!
You will also find that some of the error analysis assumes knowledge which is not described in detail until later in this book. For this reason you might want to skip forward now to section 6. In this section you will find the basic settings used to assist error monitoring, as well as some generic techniques for finding and diagnosing work items or work- flows that are in error. Many of the more specific techniques need you to be aware of some basic tech- niques.
Most are mentioned in chapter 3, Config- uring the System, but you can refer to the IMG for more details. If you are a workflow administrator, you must check your inbox regularly.
Work Item Selection. It lets you select and display work items of all types according to various criteria. Once you have found your work item this report also gives you a number of options for fixing work items in trouble.
This report is also useful if you want to get a quick overview of certain types of work items, for instance to examine back- ground work items enter work item type B to check that they are all completing promptly. Tip The task ID must be appropriate to the work item type selected. By default the selection criterion is set to show all work items that have occurred in the last hour. When specifying intervals, ensure that the second entry is later than the first.
You can also select a single work item by its ID number. Tip If you enter an ID as a selection criterion, the system ignores all other selection criteria. Setting the Output Options flag adds the columns: workflow definition number, workflow definition version, workflow administrator and executed by.
If the work item is in error, use Restart after Error. If the work item has no valid agent and you still need to execute it, use Execute without check. This option allows you to execute work items unhin- dered by access restrictions, so authorization to use this option should only be given to the workflow administrator in a production environment.
Tip If you are restarting a work item after error, make sure you restart using the administration report restart after error transaction SWPR to ensure that both the work item and the top level workflow are restarted. You should always check that the workflow has restarted correctly in case an error occurs it could even be a new error before the workflow has a chance to continue. The work item display shows detailed information about the work item and also lets you fix certain problems.
In particular in the standard display see figure 6. The stan- dard view is aimed primarily at end users. The technical display has some extra options for developers and administrators.
You can pre-set which display variant you want to use in your personal workflow settings, or use the menu options, e. Standard View Figure 6. It contains details about deadlines, statuses, agents, attachments and linked objects for a work item.
It is worth familiarizing yourself with all the features available in the work item display. If the work item execution has failed, the Messages Display Last Message function will display the error message or return codes for executed work items. All objects that are related to the work item, including the formal process objects and the ad hoc attachments, are displayed in the list of available objects on the tab page Available objects.
If no default attribute was defined for the object type, the key fields of the object are displayed. The default method of each object can be executed upon request. Tip Most objects set the Display method as the default method. So when you want to check on the details of the object, for example to help diagnose an error, you usually do not have to worry about finding the transaction needed to view it.
You can extend and process the list of objects, i. The main purpose of this is to make extra information available to the agents of the subsequent steps in the workflow, such as why you have forwarded this work item. You can see the different categories of agents. An icon is used to highlight the users that have the work item in their inboxes. Technical View All information from the displayed work item is shown in the technical work item display.
The technical work item display is particularly aimed at workflow admin- istrators. If the sym- bol is displayed as well, an escalation action was triggered by the deadline back- ground job. There you can see which event identified using an object type and event name is expected by which object identified using an object reference. This is useful if the work item has been executed but is waiting on a terminating event, as this function lets you see exactly what terminating event and event values are expected.
You can see the current, runtime-specific data on the specific work item. If you are looking at a dialog or background work item, the container belongs only to that work item. If you are looking at a workflow work item, the container belongs to the whole workflow instance. This is followed by the ID of the object type and the concatenated key of the object.
If you need to change an object reference, always use the input help on the object reference field. You can use work item selection and similar reports to find the workflow work item for your workflow. However, the work item display will only show you limited information about the workflow instance. The best way to look at the workflow instance is via the workflow log.
The workflow log formats all the information created or collected during the exe- cution of the business process i. The standard view shown in figure 6. The technical view see figure 6. In the workflow definition, you can exclude steps with the above step types from being displayed in the workflow log if you wish. If you want to see the complete log you should switch to the technical view of the log.
The tab page Workflow Chronicle shows a hierarchical display of all steps in the workflow that have been processed so far, or are currently able to be pro- cessed.
If the workflow has a subworkflow structure, the subworkflows are also displayed. The tab page Workflow Agents figure 6. The tab page Workflow Objects lists the objects related to the workflow or addressed up to now in the execution of the workflow. This view shows what objects were created and processed, and how. Figure 6. Unlike the text version of the workflow log, the graphical workflow log also shows the subsequent flow of a workflow instance.
This view also allows you to make ad hoc changes to this sin- gle workflow instance. Technical View The technical view see figure 6. For a workflow with errors it allows you to see at a glance where the error has occurred and all mes- sages including warning messages generated by the workflow. However, it is also a very useful display for determining exactly what happened during the work- flow.
You can adapt the appearance of the list to suit your requirements using layouts. Tip If you save your configuration as the initial configuration using the SAP List Viewer ALV settings control, then this view is displayed whenever you display the technical log. The technical view shows technical nodes and control structures, and makes addi- tional data available, such as container elements , agent data , and workflow data.
The status of each work item is also displayed. If the workflow is in status ERROR, the workflow log may contain a hierarchical list of underlying WebFlow Engine function modules that indicate exactly where the error was detected, helping to localize particularly obscure errors. If you choose With subworkflow structure, you decide whether or not to display any subworkflows and their structure. With error indicators to view the errors, which are marked in the log with the symbol. The standard indicator for work items that are not in error is.
This is particu- larly useful for identifying at a glance work items with errors, particularly in more complex workflows where many work items are displayed in the log. Tip By clicking on the error symbol associated with the parent workflow item at the top of the list you will be presented with a complete error analysis of the workflow, showing the probable root of the problem.
Just as with the standard view you can display a chronicle, agent or object view. That is, a work item is sent to the wrong agents or to no agents at all. Tip The WebFlow Engine cannot alert you if the wrong agent receives a work item e. This is where a good work item description comes to the rescue. Once a workflow is developed and transported to production it may not need to be changed for some time, and even changes can be planned.
With good design and thorough testing you can prevent most workflow problems. However, agent determination relies on data that is usually maintained directly in the production environment and may need to be changed at short notice. Even a relatively minor delay in updating agent determination rules or agent authorizations can have an immediate negative impact on a workflow.
The most common cause of agent determination errors is inadequate mainte- nance of the agent determination rule or the authorities given to agents. Ensuring timely maintenance of agent determination rules and workflow security can pre- vent the majority of agent determination errors. Problems can also occur because an agent has left the company, or is absent for some other reason, and has no sub- stitute, or has reserved the work item so that none of the alternative agents can access it.
The good news is that implementing simple strategies such as substitution or default agents can help alleviate agent determination problems. For more details on these and other strategies refer to chapter 5, Agents. You will probably also need to diagnose why the problem occurred and follow up any maintenance issues with the relevant personnel; otherwise the same problem will boomerang back to you on future work items. Before you fix a work item with an agent problem, always check that you have identified the correct agent; for example, check it with the business process owner.
By reading this guide you will be able to reconfigure existing applications to conform with the UWL, write UWL-specific applications or transactions and adapt data sets in order to have the appropriate work item IDs created.
Many screenshots and code samples illustrate the processes in detail, allowing you work with the UWL functionality appropriately - just as you will soon be doing in your daily work. This book provides you with the essential knowledge you need to work with SAP IDoc interfaces successfully.
Walk through the IDoc anatomy and different kinds of segments. Dive into inbound and outbound IDoc interfaces and learn how to create a port and logical system. Walk step by step through how to configure IDoc interfaces for various business scenarios including sending an invoice to an EDI partner, receiving a sales order from an EDI partner, and receiving material master data from an external system.
Learn how to use output and change pointer techniques. Examine how to monitor and troubleshoot post-IDoc interface implementation activities and get a handle on archiving best practices.
Navigate IDoc interface enhancement options including adding segments and user exits. By using detailed examples, tips, and screenshots, the author brings readers up to speed on the fundamentals of SAP IDocs. Annals of Cases on Information Technology provides a collection of case studies focusing on IT implementation in organizations. The cases included in Volume VI describe successful projects and offer advice on how to achieve these best practices.
They also look at IT project failures and describe steps to avoid pitfalls in the path to successful IT utilization. The organizations described in this book represent small businesses, educational institutions, public and private corporations and describe may aspects of IT implementation including, e-commerce endeavors, intelligent technologies, enterprise resource planning and many other facets of emerging IT utilization.
The Practical Handbook of Internet Computing analyzes a broad array of technologies and concerns related to the Internet, including corporate intranets. Fresh and insightful articles by recognized experts address the key challenges facing Internet users, designers, integrators, and policymakers. In addition to discussing major applications, it also. Reusability of information models has been discussed in science and practice for many years.
Reference models are information models that are developed with the aim of being reused for different but similar application scenarios. They primarily promise time and cost savings, since parts of the reference models can be reused. The topic of reference modeling is addressed in this book from different perspectives: Besides reference modeling languages that provide special modeling language concepts for the development and application of reference models, reference modeling methodologies are discussed, which additionally provide procedure models for the construction and application of reference models.
Moreover, particular reference models are discussed and evaluated. Understand work item delivery and agents, and learn how to activate SAP-provided workflows. Learn how to make sure that workflows are properly executed, and how to fix things when they go wrong.
From upgrading, to troubleshooting, to diagnostics, the information is all here. Know how to create a workflow from scratch. You'll find basic builder tasks, advanced techniques, and information on editors and ABAP techniques. He has been with SAP since and in data processing since In , he joined the SAP Business Workflow group performing development work as well as consulting for various blue-chip U.
DJ Adams is a principal at Bluefin Solutions and has been working with SAP enterprise software since , specializing in integration, and has a strong connection to the Open Source community.
Since joining SAP development in , he led various programs across the SAP Business Suite in topics such as reporting, user experience, or architecture—always in close collaboration with customers. He comes from a consulting and development background, so he understands both the technical and functional aspects of SAP ERP HCM and can communicate them clearly to any audience. Starting with Dell Inc. Amol Palekar has worked on BI programs for various Fortune companies.
Mike Pokraka is a freelance consultant who has been working with SAP since the s. Andreas joined SAP in As a technology consultant, he helped organizations all over the world solve their data and process integration challenges.
0コメント