`
`(cid:201)´(cid:212)
`
`Image and Workflow Library:
`FlowMark V2.3 Design Guidelines
`
`Bob Stegmaier Mike Ebbers Tomislav Begovac
`
`International Technical Support Organization
`
`http://www.redbooks.ibm.com
`
`SG24-4613-02
`
`Starbucks Corp. Exhibit 1038
`
`
`
`
`
`Starbucks Corp. Exhibit 1038
`
`Starbucks Corp. Exhibit 1038
`
`
`
`(cid:201)´(cid:212)
`
`International Technical Support Organization
`
`SG24-4613-02
`
`Image and Workflow Library:
`FlowMark V2.3 Design Guidelines
`
`February 1998
`
`Starbucks Corp. Exhibit 1038
`
`
`
`
`
`Take Note!
`
`Before using this information and the product it supports, be sure to read the general information in Appendix C, “Special
`Notices” on page 29.
`
`
`
`
`
`
`Third Edition (February 1998)
`
`This edition applies to Version 2 Release 3 of IBM FlowMark, Program Number 5697-216 for use with the OS/2, Windows NT and
`AIX Operating Systems.
`
`Comments may be addressed to:
`IBM Corporation, International Technical Support Organization
`Dept. HYJ Mail Station P099
`522 South Road
`Poughkeepsie, New York 12601-5400
`
`When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any way it believes
`appropriate without incurring any obligation to you.
`
` Copyright International Business Machines Corporation 1996, 1998. All rights reserved.
`Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure is subject to
`restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
`
`Starbucks Corp. Exhibit 1038
`
`
`
`
`
`
` Contents
`
`Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
`The Team That Wrote This Redbook
` v
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Comments Welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
`
`Introduction and Overview .
`Chapter 1.
`.
`.
`.
`.
`1.1 Basic Concepts of FlowMark
`.
`.
`.
`.
`.
`.
`.
`.
`.
`1.2 FlowMark Buildtime: Defining Your Processes
`
`Importance of Process Design
`Chapter 2.
`2.1 Function, Performance, and Capacity
`2.2 Understand the Basis: FlowMark V2.3
`
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`Chapter 3. Client/Server Can Mean Multiple Servers
`3.1 Multiple Server Options with FlowMark V2.3
`.
`.
`.
`3.2 Dedicating Your FlowMark Servers .
`.
`.
`.
`.
`.
`.
`.
`
`.
`
`Chapter 4. How Big is a Process?
`.
`.
`.
`.
`.
`4.1 Performance and Capacity Considerations
`
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
`. 1
`. 1
`. 1
`
`. 3
`. 3
`. 4
`
`. 5
`. 5
`. 6
`
`. 7
`. 7
`
`Chapter 5. Starting and Deleting Process Instances
`. 9
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`5.1 Starting Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
`5.2 Deleting Process Instances
`. 9
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
` 10
`5.3 Performance and Capacity Considerations
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`Chapter 6. How Big is an Activity? .
`.
`.
`.
`.
`6.1 Performance and Capacity Considerations
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`Chapter 7. How Many People Do I Assign to an Activity? .
`7.1 Performance and Capacity Considerations
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`Chapter 8. When Do I Use an Activity Block?
`8.1 Performance and Capacity Considerations
`
`Chapter 9. When Do I Use a Subprocess?
`9.1 Performance and Capacity Considerations
`
`.
`
`.
`
`.
`.
`
`Chapter 10. Data Container Usage
`.
`.
`.
`.
`.
`.
`.
`10.1 Performance and Capacity Considerations .
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
` 11
` 11
`
` 13
` 14
`
` 15
` 15
`
` 17
` 17
`
` 19
` 19
`
`Chapter 11. Using FlowMark Functions Wisely
` 21
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`11.1 Sign On and Sign Off
` 21
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`11.2 Shut Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
`11.3 Filtering Work Lists and Process Lists
` 21
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`11.4 Refreshing Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
`11.5 Using the Monitor
` 22
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`11.6 FlowMark Bundle Activities .
` 22
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`Appendix A. Factors Influencing the Size of a FlowMark Data Base
`A.1 Activity Name and Description
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`A.2 Results of Staff Resolution
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
` Copyright IBM Corp. 1996, 1998
`
`.
`.
`.
`
`
`
` 25
` 25
` 26
`
`iii
`
`Starbucks Corp. Exhibit 1038
`
`
`
`
`
`
`
`
`A.3 Data Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
`A.4 Other Things
` . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
`
`Appendix B. The FlowMark Internet Site
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
` 27
`
`Appendix C. Special Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
`
`Appendix D. Related Publications . . . . . . . . . . . . . . . . . . . . . . . . 31
`D.1 International Technical Support Organization Publications
` 31
`.
`.
`.
`.
`.
`.
`.
`.
`.
`D.2 Redbooks on CD-ROMs
` 31
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`D.3 Other Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
`
`How to Get ITSO Redbooks .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`How IBM Employees Can Get ITSO Redbooks
`How Customers Can Get ITSO Redbooks
`.
`.
`IBM Redbook Order Form .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
` 33
` 33
` 34
` 35
`
`Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
`
`Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
`
`ITSO Redbook Evaluation .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
` 51
`
`iv FlowMark V2.3 Design Guidelines
`
`
`
`Starbucks Corp. Exhibit 1038
`
`
`
`
`
`
` Preface
`
`This redbook tells you how to design your FlowMark processes to optimize
`performance, capacity and resource utilization. This version has been updated for
`IBM FlowMark V2.3 and runs on the OS/2, NT and AIX platforms.
`
`It was written for technical professionals such as solutions architects, consultants,
`and application programmers who are implementing a FlowMark system. Some
`knowledge of FlowMark and client/server issues is assumed.
`
`The Team That Wrote This Redbook
`This redbook was produced by a team of specialists from around the world working
`at the International Technical Support Organization, Poughkeepsie Center.
`
`Bob Stegmaier is a Senior Marketing Support Representative at IBM's Dallas
`Systems Center in Roanoke, Texas, USA. Ever since FlowMark was announced,
`Bob has consulted with customers worldwide in all areas of FlowMark and written
`technical documents. He has been with IBM for 30 years, including a variety of
`programming assignments and 10 years with the Dallas Systems Center. He has a
`degree in economics from George Washington University in Washington D.C.
`
`Tomislav Begovac is at the IBM FlowMark Competency Center in Boeblingen
`responsible for FlowMark technical support in EMEA (Europe, Middle East, and
`Africa). Before his current assignment, he was managing the development tools
`department in the IBM German Software Development Lab. Tomislav can be
`reached at beg@de.ibm.com.
`
`This redbook was published by the International Technical Support Organization.
`
`Mike Ebbers is a Senior International Support Representative at the International
`Technical Support Organization, Poughkeepsie Center. He has worked at IBM for
`24 years. He produces redbooks on workflow and image products. Mike
`previously developed Education and Training courses on imaging and printing.
`
`Thanks to the following people for their invaluable contributions to this project:
`
`Joachim Schmitz
`German Software Development Lab
`Boeblingen, Germany
`
`Mike Lang
`IBM National Technical Support
`Dallas Systems Center
`
`For updating the redbook for FlowMark Version 2.3, thanks to:
`
`Tomislav Begovac
`German Software Development Lab
`Boeblingen, Germany
`
` Copyright IBM Corp. 1996, 1998
`
`
`
`v
`
`Starbucks Corp. Exhibit 1038
`
`
`
`
`
`
`
`
` Comments Welcome
`Your comments are important to us!
`
`We want our redbooks to be as helpful as possible. Please send us your
`comments about this or other redbooks in one of the following ways:
`(cid:159) Fax the evaluation form found in “ITSO Redbook Evaluation” on page 51 to the
`fax number shown on the form.
`(cid:159) Use the electronic evaluation form found on the Redbooks Web sites:
`http://www.redbooks.ibm.com/
`For Internet users
`http://w3.itso.ibm.com/
`For IBM Intranet users
`(cid:159) Send us a note at the following address:
` redbook@us.ibm.com
`
`
`
`vi
`
`FlowMark V2.3 Design Guidelines
`
`
`
`Starbucks Corp. Exhibit 1038
`
`
`
`
`
`
`Chapter 1.
`
`Introduction and Overview
`
`Workflow management helps you manage and control your business processes,
`pinpoint areas for improvement, and streamline your procedures for speedier cycles
`and shorter response times. By defining the flow of work, everyone is notified of
`outstanding work and presented with the required information and an appropriate
`application to perform the task.
`
`1.1 Basic Concepts of FlowMark
`FlowMark is a tool to help you automate and streamline your business processes.
`This is critical for success in today's business environment. FlowMark was written
`as a pure application-independent workflow engine which manages the flow of work
`throughout your organization.
`It does not have roots in forms, document or image
`workflow as some other products do. FlowMark helps you harness the power of
`other applications to handle individual tasks. You decide which applications are
`best suited to assist you in performing these individual tasks.
`
`FlowMark is designed to handle the flow of work from user to user, following the
`business rules specified in your business process. Users have a work list (or
`perhaps more than one) where activities are placed automatically when the flow
`through a “process instance” determines there is something for them to do. The
`users select the next item they wish to work on from the list, and FlowMark calls
`the appropriate application program (defined in the process design) to perform that
`task. Often it is an application the users already understand. They can work in the
`application as long as needed to complete the task. When the program returns to
`FlowMark, the server is notified, and navigation continues through the process to
`the next activity or activities to be done. These then appear on the work lists of the
`people responsible for completing them.
`
`While FlowMark has a user-oriented view, it is also able to include in the process
`flow both automatically started activities, that start immediately on a single user's
`desktop, and what are called “unattended” activities. These are batch jobs that
`expect no user interaction and are started automatically. Some process designs
`achieve the same function by assigning an activity to a specific user, specifying that
`it start automatically. The program is implemented so that it executes without any
`user interaction.
`
`1.2 FlowMark Buildtime: Defining Your Processes
`“Buildtime” is the definition facility of FlowMark. This is where you define your
`processes and their hierarchies, assign programs to activities, and allocate staff
`such as people or roles. The following definition facilities are provided:
`(cid:159) The Process Definition facility is where you specify and maintain process
`models as activity networks. These can involve multiple steps and many users.
`The creation and manipulation of activity networks is done with a graphical
`interface. An activity network can be considered to be a directed graph, where
`the nodes represent activities to be performed and the connectors between the
`nodes represent either control flow or data flow. The control flows can be
`unconditional or conditional.
`If conditional, then a Boolean expression is
`associated with the connector.
`
` Copyright IBM Corp. 1996, 1998
`
`
`
`1
`
`Starbucks Corp. Exhibit 1038
`
`
`
`
`
`
`
`
`(cid:159) The Staff Definition facility is used for the definition of staff personnel to which
`activities could be assigned.
`It maintains information about people, skill levels,
`roles, organizations, their relationships and their authorizations.
`(cid:159) The Program Registration facility is used to register programs that are invoked
`at process execution by an activity, and to specify input/output parameters for
`the programs. All programs that you wish to attach to an activity (including
`those used as “tools”) must be registered.
`(cid:159) The Data Structure Definition facility is used to define the structure of the
`information (in data containers) that is transported from a program to FlowMark
`and from FlowMark to a program. The data structures can also be used to
`transport data to/from activity blocks and subprocesses.
`(cid:159) The Server Definition facility is used to define the various FlowMark servers in
`an enterprise. All servers to be used for the execution of remote subprocesses
`must be registered.
`
`These are the FlowMark Buildtime facilities that you will use to design your
`processes.
`In the use of these facilities, the guidelines in this redbook will come
`into play.
`
`2 FlowMark V2.3 Design Guidelines
`
`
`
`Starbucks Corp. Exhibit 1038
`
`
`
`
`
`
`Chapter 2.
`
`Importance of Process Design
`
`It must
`The design of your processes is critical to the project and to your business.
`be done well. You should expect to refine your processes on an ongoing basis.
`Since FlowMark provides data in the audit trail on process performance, you can
`more easily find the weak points in the processes. Since the “process flow” is now
`in FlowMark and not buried deep in a large application, it is easy to make the
`changes necessary to achieve the improvements.
`
`2.1 Function, Performance, and Capacity
`FlowMark will automate your processes, make them reliable, and see that they run
`quickly.
`If poorly designed processes caused you to move to workflow automation,
`keeping the same process design will merely automate the problem.
`It is important
`that you have quality processes defined before you start prototype testing with
`users. They need not be perfect, but quality should be evident.
`
`On the other hand, you may already have good processes defined. But you can
`use FlowMark to speed the flow from user to user, call the correct application so
`the user does not need to remember how, pass data from user to user so it does
`not have to be repeatedly entered, and see that the business rules are followed
`exactly as defined even when the users do not remember the nuances of particular
`exception cases.
`
`Process design touches everything: the way people work, the speed at which things
`get done, the results the customer sees (or never sees), the performance and
`capacity of the FlowMark server and database, the demands on the LAN, and the
`underlying application.
`
`There are no hard-and-fast rules. There are always business reasons to do things
`in a different way. But, especially for new users, guidelines can be helpful. As you
`gain experience, you can modify these to fit your own business.
`Included here are
`some ideas about capacity and performance.
`It is never too early to begin thinking
`about performance. As you are designing, everything you create influences the
`performance of your business application.
`
`Some of your processes may fit easily within these guidelines, while others may
`not.
`If those that fit are the most frequently used (the ones with the highest volume
`of instances or activities), your design should work just fine. However, if you do
`things that have a negative impact on performance or database capacity, even a
`little bit, and they occur many times per hour or per day, the cumulative impact on
`your system can be serious. Sometimes it is not so much what you do, but how
`many times you do it, that determines the real impact.
`
`It helps to do
`It is important to understand the workload volumes in your system.
`some basic math: the number of instances per day times the number of activities
`per instance times the number of users. The result can be enlightening. Additional
`hardware can often overcome performance and capacity limitations. Sometimes
`that is the right answer.
`
`It is impossible to teach everything there is to know about processes here, but
`there are some frequently asked questions to think about.
`
` Copyright IBM Corp. 1996, 1998
`
`
`
`3
`
`Starbucks Corp. Exhibit 1038
`
`
`
`
`
`
`
`
`2.2 Understand the Basis: FlowMark V2.3
`The suggestions in this redbook are based on FlowMark as it is implemented in
`Version 2 Release 3, the generally available (GA) level of code. As early users find
`new and intriguing ways to solve their business problems using workflow, they will
`at times desire functions that are not offered or find uses that exceed the capacity
`intended by the original design. While the following information reflects some of
`these limitations, enhancements are being developed in FlowMark to remove
`constraints and provide new functional capability. Please use this only as a guide
`for the use of FlowMark Version 2 Release 3.
`
`While this document reflects the implementation in V2.3, you can expect
`enhancements. When new releases become available, understand what they
`provide and do not let this document deter your use of the added functions.
`
`4 FlowMark V2.3 Design Guidelines
`
`
`
`Starbucks Corp. Exhibit 1038
`
`
`
`
`
`
`Chapter 3. Client/Server Can Mean Multiple Servers
`
`While FlowMark is a client/server tool, do not limit your thinking and design to a
`single server. You should consider capacity and performance in your design, and
`there are times when you will need multiple servers to achieve your goals,
`particularly if you are designing something larger than a departmental system. You
`may need to ask this question: “How many servers, and of what kind, do I need to
`achieve my business requirements?” Do not inhibit your design by thinking:
`“How
`do I constrain my design so it works on a single machine?”
`In today's world of
`constantly improving price/performance, hardware may not be as significant an
`impact on the overall cost of a project as it once was.
`Investigate the cost
`implications and approach the topic with an open mind.
`
`If you intend to start with a single server, but expect over time to add more users or
`more applications to your workflow platform, make sure you plan and design with
`the concept of multiple servers in mind. How will you divide the work between
`servers? Will you have a different set of users per server, with some people in
`each set capable of performing all activities for each process run on that server?
`Will you want to eventually move part of a process to a different server while
`keeping the “main part” on a current server, thus requiring use of a subprocess?
`This planning will make it much easier later when you add additional servers.
`
`Consider the concept of a red team, a white team, and a blue team, each with its
`own server, each independently running the same process template, doing the
`same kind of work. Or perhaps you prefer different servers with different types of
`users doing different processes or subprocesses. Perhaps your application calls for
`regional servers serving local offices, running a process that under some
`circumstances needs to run a subprocess for headquarters approval. You could
`have two or more regional servers, each with its set of users doing the local
`activities, and a single headquarters server where that staff does the tasks in the
`approval subprocesses for all regions.
`
`3.1 Multiple Server Options with FlowMark V2.3
`FlowMark supports servers with OS/2, Windows NT, AIX and HP-Unix operating
`systems. The OS/2 and NT platforms give some range of scalability within the
`hardware where it runs. AIX gives you a step up in performance and capacity and
`a broad scale of available hardware in the RS/6000 family. You can start small and
`step up in platforms (even change operating systems) with little effort. This
`involves a change of servers, but there is no change required in your process
`models; they can be moved as is. Also, there is no change required on your client
`workstations. Both server environments support all client environments.
`
`If a single server is not the solution to do your job, what are the options available
`with FlowMark V2.3?
`(cid:159) Simply divide the work. Have different server machines, with different
`databases and FlowMark servers for subsets of the users. Divide the users by
`teams, by organizations, by location. You will need to have a mix of users on
`each server machine so that all activities in the processes you want to run on
`that server can be completed by the users there. This could influence your
`process design.
`
` Copyright IBM Corp. 1996, 1998
`
`
`
`5
`
`Starbucks Corp. Exhibit 1038
`
`
`
`
`
`
`
`
`The expectation in this concept is that each server and database combination
`are independent of any other. There is no communication between FlowMark
`servers. However, this solution could, over time, be combined with the
`following option.
`(cid:159) Have processes on one or more servers perform subprocesses on other
`servers. This function in V2.3, introduces the concept of domains. A domain is
`what most people consider as the “FlowMark server,” the FlowMark Runtime
`server and its database. In Buildtime, there is a new selection on the primary
`menu called Servers. From there, you define each “server” in the system as an
`object along with its network address and communications protocol. Then,
`when you create a subprocess icon in process design, you specify on which
`server this is to run, on the “Server” page in the notebook. That page also
`allows the server to be specified in a data structure member of the process
`activity's input (source) container. The subprocess template must be located in
`the database of the other server, and all staff resolution (who does which
`activities) is done on that other server based on the staff defined in its data
`base. This would follow the regional and headquarters example discussed
`above.
`
`If you conclude that you need to have multiple OS/2 or NT servers, consider the
`other server platform option, AIX. A single fast AIX server can do the same work
`as several OS/2 or NT servers.
`It does involve a change in operating system,
`which may have training and skill implications, but it may be the better choice.
`
`These capabilities may not provide you with the ideal solution that you would like to
`see immediately. But it is the goal of FlowMark developers to provide you with an
`enterprise solution. They are working to give you increasing levels of function to
`connect a growing number of users within the overall workflow framework. You will
`implement your solution today within the current capabilities of FlowMark, but you
`should design with the intent of eventually expanding the horizon.
`
`3.2 Dedicating Your FlowMark Servers
`If you put other
`It is best to have your FlowMark servers as dedicated machines.
`applications on the server machines, there is a good possibility that you will
`sometimes affect the service you give to your FlowMark users. Even “small”
`applications that use resources only occasionally can use significant resources
`during the few times they need them. These blips in usage can result in poor
`response times for users who are sharing that server.
`
`If you have excess capacity on a server and need to use it for something other
`than FlowMark, then understand the risks and keep an eye on what these other
`things do. They may impact processor utilization and may also cause conflicts in
`memory (swapping) or disk I/O.
`
`6 FlowMark V2.3 Design Guidelines
`
`
`
`Starbucks Corp. Exhibit 1038
`
`
`
`
`
`
`Chapter 4. How Big is a Process?
`
`How big should a process be? How much of the business should it encompass?
`How many activities should it contain? The answer lies somewhere between bigger
`than the head of a pin and smaller than a galaxy. Again, there are no
`hard-and-fast rules, but some guidelines can help.
`
`If one person
`If the process has only one or two activities, it is probably too small.
`does “this” then “that” and is done in one minute, then FlowMark may not add much
`to the work effort. But is this “process” really part of a bigger picture? Look at the
`front and back ends to see if these two activities are really part of a larger business
`process. Or perhaps there are exception conditions that result from special cases
`or errors that are discovered by the work done in these activities. These may show
`that you really have a larger process to consider.
`
`If you expect to run the entire corporation with one massive looping process, then
`the process is probably too big. A process should represent the steps needed to
`satisfy a specific request from a customer or employee. Sometimes you may want
`to break a request into multiple processes.
`
`While it is not possible to define the ideal number of activities for a process model,
`we can use a guideline of 5 to 20 activities.
`If you have more than 20, consider
`breaking it up by using starts of independent processes or by using subprocesses.
`If you have fewer than five, consider combining processes or folding in exception
`conditions as mentioned above.
`
`You may begin your first implementation with fewer activities, with the plan to bring
`more outside activities into the process model as you gain experience in workflow.
`You might automate only a part of a business process, expecting to add more to it
`after gaining some experience. Here, a smaller process than the guidelines
`suggest would be acceptable.
`
`What about exception processing? Should it be part of the process, or a separate
`process? Maybe. (Remember: no rules, just guidelines.) If exceptions are part of
`the business and do not last markedly longer than the average process, maybe
`they are just part of the process. But let's say you have a process to handle
`customer orders and shipping, and occasionally a damaged order arrives at the
`customer, which starts a six-month-long involvement of insurance companies,
`lawyers, and lawsuits.
`In this case it might be better to have an activity in the main
`process call the FlowMark API to start a separate damaged order claim process
`and pass appropriate information in the source container to that process. Allow the
`main order and shipping process to complete separately. All the needed
`information should be in your application database, available to the damaged order
`claim process.
`
`4.1 Performance and Capacity Considerations
`It
`Creating a process instance influences both performance and database size.
`involves copying parts of the process template, inserting the new instance into the
`database, and then doing some evaluation at the process level, staff resolution, and
`updating process lists for those users who have it displayed. As this is a non-trivial
`amount of work for the server, make sure there is payback. Very short one- or
`
` Copyright IBM Corp. 1996, 1998
`
`
`
`7
`
`Starbucks Corp. Exhibit 1038
`
`
`
`
`
`
`
`
`two-activity processes (or subprocesses) need to be questioned as they will entail
`this overhead, which is much more than just “inline” activities. On the other hand, a
`very large process, with many activities and long paths that are infrequently used
`because of the transition conditions, can impact database size. The process
`instance size is influenced by the number of activities, and the instance takes this
`database space as long as it exists, although noticeably less in V2.3 than with
`earlier releases. See Appendix A, “Factors Influencing the Size of a FlowMark
`Data Base” on page 25, which describes some of the fields in a process template
`that influence the amount of data stored for each instance and thus the size of the
`database.
`
`If you see the need for a one- or two-step process with both steps done by the
`same person, or you have a process where most of the instances are ended by a
`single person after a step or two, then consider the following idea. Often the
`business event that causes a process instance will record that information in a file
`or queue that is serviced by a program that creates the process instance. You
`could have a “constant” process, an instance for each person, which has the single
`step typically done. When the user selects this activity from the work list, the
`program does a “get next” from this queue of work and does the task.
`It then is
`designed to fail the exit condition, so that it goes back as ready on the user's work
`list.
`
`If a special condition or exception case is determined which requires further
`processing, then instead of setting condition data in the output container to have a
`larger process continue, it could use an API call to start another process that would
`do that additional processing. This concept can eliminate much of the overhead of
`creating very many short processes, yet provides the ability to handle more
`complex exception conditions, all using the FlowMark work list as a single place to
`find the things you need to do. This can also help in reducing the large number of
`people being shown a single item (see Chapter 7, “How Many People Do I Assign
`to an Activity?” on page 13).
`
`8 FlowMark V2.3 Design Guidelines
`
`
`
`Starbucks Corp. Exhibit 1038
`
`
`
`
`
`
`Chapter 5. Starting and Deleting Process Instances
`
`The most obvious way to start a FlowMark process is to open your process list,
`copy a process template and start the instance manually. But it is probably better
`to provide a simple FlowMark API program to do that. This program could be
`accessible to users via an icon on their desktop, or could be called by one of your
`application programs that determines the need for a process to start as the result of
`some business event.
`
` 5.1 Starting Instances
`If you have an application that collects many of these requests, be careful when
`you decide to start many process instances. Starting 200 instances might be fine
`in the middle of the night when there are no users on the system. But a program
`that does this during normal working hours will likely take over the server, much to
`the detriment of user response time.
`If you do have the need to process
`accumulated queues of requests during working hours, consider programming a
`delay in the creation loop to give your users a chance to get their work done.
`
`Investigate the ExmcStartProcess API call. While doing that, consider providing the
`instance name yourself. You will find that having instance-specific information in
`the process instance name makes using your process list, the monitor and the audit
`trail much easier. Customer name, invoice number, account number and other
`information might be made part of the instance name.
`
`5.2 Deleting Process Instances
`A process instance is called “finished” when the workflow has progressed through
`all defined activities to the end of the process. A process instance is called
`“terminated” if the process was forced to finish by an authorized user or by the API
`call ExmTerminateProcess.
`
`Finished or terminated process instances are automatically removed from the work
`lists and deleted from the database if the user who creates the process instance
`has checked the checkbox “Delete finished items” in the personal data settings
`notebook.
`It lets you define the following for each user:
`(cid:159) Activities that have the status finished, disabled, or force-finished are
`automatically deleted from the user's work list.
`(cid:159) Process instances created by the user with the status finished or terminated
`are automatically deleted from the database when they are finished or
`terminated.
`
`Whenever an instance is deleted, all activities for the process instance are deleted
`from the work lists, as are all subprocesses for the process instance.
`
`If the “Delete finished items” checkbox is not checked, you have several other
`options for deleting process instances:
`(cid:159) Delete them manually from the process list.
`(cid:159) Have them automatically deleted by the server. after a spe