当前位置：文档库 › Integrating Light-Weight Workflow Management Systems within Existing Business Environments

Integrating Light-Weight Workflow Management Systems within Existing Business Environments

Integrating Light-W eight W orkflow Management Systems within Existing Business Envir onments Peter Muth, Jeanine Weissenfels, Michael Gillmann, Gerhard Weikum

University of the Saarland

{muth,weissenfels,gillmann,weikum}@cs.uni-sb.de, http://www-dbs.cs.uni-sb.de

Abstract

Workflow management systems support the efficient, lar gely au-tomated execution of business processes. However, using a workflow management system typically r equir es implementing the application’s contr ol flow exclusively by the workflow management system. This approach is powerful if the control flow is specified and implemented from scratch, but it has severe drawbacks if a workflow management system is to be integrated within environ-ments with existing solutions for implementing contr ol flow. Usual-ly, the existing solutions are too complex to be substituted by the workflow management system at once. Hence, the workflow man-agement system must support an incremental integration, i.e. the reuse of existing implementations of contr ol flow as well as their in-cremental substitution.

Extending the workflow management system’s functionality ac-cording to future application needs, e.g. by worklist and history management, must also be possible. In particular, at the beginning of an incremental integration process, only a limited amount of a workflow management system’s functionality is actually exploited by the workflow application. Later on, as the integration pr oceeds, more advanced requirements arise and demand the customization of the workflow management system to the evolving application needs.

In this paper, we pr esent the ar chitectur e and implementation of a light-weight workflow management system, coined Mentor-lite, which aims to over come the above mentioned shortcomings of con-ventional workflow management systems. Mentor–lite supports an easy integration of workflow functionality into an existing envir on-ment, and can be tailored to specific workflow application needs.

1Introduction

When a workflow management system is used to implement a computer supported business process from scratch, all the function-ality of the workflow management system can be fully exploited. In particular, the control flow will be completely specified in the workflow management system’s specification language, and the invocation of workflow activities according to the specified control flow will be completely controlled by the workflow engine at exe-cution time. In particular, external applications that are called by the activities of a workflow can be integrated by means of a simple invocation interface (e.g. using CORBA or DCOM). This is what virtually all currently available workflow management systems provide and the workflow management coalition (WfMC) pro-poses an architecture along these lines [39].

1.1Problem Statement

However, only in rare cases there is an opportunity to computer-ize a business process from scratch. Typically, computer support for business processes has been implemented before workflow

This work was performed within the research project “Architecture, Con-figuration, and Administration of Large Workflow Management Sys-tems” funded by the German Science Foundation (DFG).management systems are introduced. This is not only true for the application programs implementing the activities of a workflow, but also for the control flow. Examples are shell scripts for invoking application programs according to the outcome of other applica-tions, timer-controlled invocations of applications, stored database procedures in combination with trigger definitions, or even pro-grams in high-level programming languages that access databases and invoke other applications. In the following, we refer to such ex-isting control flow implementations as scripts. Since existing busi-ness environments typically mix scripts and activities, they quickly become very complex to maintain and to adapt to new application needs. Workflow management systems provide a solution, but us-ing them typically requires all control flow to be reimplemented. The costs of such reimplementation are often prohibitive. Even more important, initial problems with the new implementation are very likely to occur and may cause the entire application environ-ment to be unavailable for a long time. Only if a smooth transition from the old “hand-made” workflow to a workflow management system supported implementation is possible, workflow manage-ment systems will gain more acceptance for usage in existing busi-ness environments. A smooth transition requires the incremental substitution of scripts by facilities of the workflow management system. These incremental steps can be performed whenever the corresponding part of the business process needs to be modified or extended anyway. From a technical point of view, this requires means to incorporate scripts into the specification language of the workflow management system, and it requires interfaces from the workflow management system to the scripts.

Even if the required features of the specification language and the required interfaces exist, the usage of workflow management systems is often prohibited by their huge system footprint. This is particularly important if only a small part of their functionality is (currently) exploited. Used in such a way, current workflow man-agement systems are too expensive, create too much overhead or simply do not perform well enough.

To make things worse, even the most full-fledged workflow management systems suffer from limited extensibility. Although most systems were designed to support diverse kinds of workflow applications, optional administration facilities like worklist man-agement and history management are often not powerful enough and can not be suf ficiently tailored to application needs. The prob-lem is that the requirements posed on these components by dif fer-ent workflow applications are as diverse as the workflow applica-tions themselves. For example, the need for complex strategies for assigning work items to actors, such as load balancing between ac-tors and the principle of dual control, can not be predicted in ad-vance. In essence, administration facilities are small workflows themselves, and require support of almost all components of the workflow management system. This observation is not properly re-flected in most architectures of workflow management systems today, as administration facilities are not considered as an integral part of the workflow management system.

1.2Contribution of the Paper

Based on the above observations, the need for a review of cur-rent architectures of workflow management systems is obvious. A new architecture must support an easy, incremental integration of

workflow management systems into existing environments, must consider tailorable administrative facilities as an integral part, and must aim at minimizing the system footprint.

We advocate a light-weight system architecture that is based on a “slim” workflow management kernel, yet can be adapted to the full spectrum of applications through appropriate extensions. We argue that protocols for integrating scripts as well as optional workflow administration functionality should themselves be im-plemented as workflows. This novel technique distinguishes our approach from earlier proposals towards light-weight and adapt-able architectures. However, there is always a tradeoff between a simple kernel architecture with limited functionality and the bene-fit of sharing functionality of a rich kernel. The challenge is to clear-ly identify the required kernel functionality and its interfaces. 1.3Related Work

The problem of designing interfaces to existing applications has challenged system designer long before research on workflow management began. In the area of database integration, so called mediators [40] were developed. The aim of mediators is to make data stored in dif ferent data sources, which even use dif ferent data models, available in a homogeneous manner. These data sources need themselves be prepared for the integration by surrounding each of them with an appropriate wrapper. The approach involves basic interface design, means for implementing dataflow, transla-tion mechanisms, and even data repositories for maintaining meta data describing the various data sources. The most notable projects in this area are the IBM Garlic project [30], the DISCO project [21,26], and the TSIMMIS project [16,22]. In contrast to the needs of workflow management systems, however, these projects focus on connecting data sources, not on connecting application pro-grams in general.

Many applications today use common web standards such as HTML to solve interoperability problems. This approach has also been adopted by workflow management systems. DartFlow [6] and Staffware Global [34] use web pages with embedded Java applets as its front end. The interface of Panta Rhei [10] to client applica-tions and to remote systems is solely based on the exchange of HTML forms. However, these approaches address only the client issues of interoperability, not the connection to existing scripts and applications.

For the invocation of external applications, distributed pro-gramming environments like CORBA or DCOM [13] can be used. They make distribution transparent and even provide basic transac-tion services. For example, CORBA is used by the OrbWork [33] workflow enactment service as part of the Meteor2 project. In Me-teor2, an alternative enactment service, W ebW ork [23] solely based on web technology has also been developed. In Lotus Notes [29], OLE2 capabilities are used to integrate application programs. However, in Lotus Notes many different interfaces and languages like agents, macros and Lotus-Script can also be used to expand in-terface functionality.

Work closely related to our approach is done in the MOBILE project. There, existing (legacy) application programs are inte-grated into the MOBILE workflow management system [19] by means of a specific wrapping mechanism for application programs [12,32]. The emphasis is on reliability and recovery aspects. There-fore, the authors distinguish between transactional and non-trans-actional application programs. A similar approach is also pursued in Meteor2by considering different task types.

None of the above work considers the integration of existing scripts, i.e., making them available as building blocks for workflow applications. Hence, to the best of our knowledge, our approach to incrementally integrate existing scripts both in terms of basic inter-faces as well as in terms of the workflow specification language is a novel idea and has not been considered elsewhere.

In addition to the interface problem, tailoring of workflow man-agement systems to specific workflow application needs has be-come an important issue. However, most workflow management systems, both products and research prototypes, are rather mono-lithic and aim at providing full fledged support for the widest pos-sible application spectrum [1,7,9,11,20,37]. On the other hand, the idea of extensible and adaptable system architectures is not new. Extensible database systems have been investigated in research and development for a decade, with mixed success but wide agreement that this is the right architectural paradigm [5]. A similar paradigm is being pursued for constructing highly adaptable, distributed middleware [2, 3]. In the area of workflow management, however, the need for extensible and adaptable architectures has not received much attention so far, with the most notable exceptions being the MOBILE [19,20], Meteor2 [23,33], INCA [4], and WASA [38] projects. Our specific approach towards an extensible, light-weight system, namely, viewing major extension components as work-flows themselves, is, to the best of our knowledge, a novel idea.

1.4Outline of the Paper

Based on an example scenario, we reason about the architectur-al decisions we made for our light-weight workflow management system, Mentor-lite. Discussions of important implementation as-pects of Mentor-lite show the feasibility of our approach. The paper is or ganized as follows. In Section 2, we give a detailed discussion of the architectural requirements based on an example scenario. Section 3 presents the basic architecture of Mentor-lite. Section 4 discusses how Mentor-lite can be integrated into an existing envi-ronment. Section 5 concludes the paper.

2Architectural Requirements

Two architectural requirements have mainly driven the design of our workflow management system Mentor-lite. First, it must be easy to integrate Mentor-lite into existing computerized business processes. Second, the development and extension of facilities like worklist management and history management must not be harder than designing a workflow itself.

In order to discuss these requirements, we present a simple workflow scenario in an electronic commerce environment. It con-siders a lar ge mail order business selling expensive electronic de-vices such as high-end computers and telecommunication equip-ment. We will focus on the main business process, i.e. registering incoming orders and delivering the ordered items, for discussing our scenario.

Assume that our mail order business has already computerized parts of the business process. Incoming orders by mail or phone are registered in a database. As high-end electronic devices are expen-sive, the credit-worthiness of each customer is checked before the order is processed. This is done by automatically consulting a cor-responding online service, e.g. by using encrypted e-mail. If the check is successful, the inventory database is checked to see if the ordered items are in stock. If this check is also positive, an invoice is printed and the ordered items are delivered to the customer together with the invoice. The control flow of the business process is imple-mented by simple scripts and application programs, e.g. using em-bedded SQL. Such an implementation can be found in many enter-prises today where workflow management systems are not (yet) used.

2.1Integrating Control Flow Scripts

Now assume that our mail order business wants to exploit the Internet to present its products. Customers should be able to place orders via the web. In this case, no invoice will be sent. Instead, payment will be done through credit cards. This extension of the main business process requires additional activities to be integrated into the business process, e.g. registering orders that come through the web, and the substitution of existing activities, e.g., checking a customers credit card instead of her credit-worthiness. In addition, modifications of the current control flow scripts are required to in-corporate the new activities.

In order to implement the new business process, the mail order business might either choose to modify the existing scripts, or un-

dertakes the adventure of reimplementing its business processes by using a workflow management system. In the first case, the mail or-der business will face the same problem again if future extensions are necessary. In the second case, all investments in the current im-plementation of control flow are lost. If dependencies with other business processes of the enterprise exist, all the business processes have to be reimplemented at once. This also includes existing wrap-pers to application programs that perform activities in the business process. In addition, initial problems with the new implementation are very likely to occur. There is a high risk of not being able to do business for days or even weeks until all transition problems are solved.

This consideration clearly shows that workflow management systems must support a smooth transition from “manually” imple-mented control flow to control flow handled by the workflow man-agement system. T o do so, it is important that a workflow manage-ment system is able to integrate the existing implementations for handling control flow. Later, these scripts can be incrementally sub-stituted by the workflow management system.

Most workflow management systems today only have an inter-face to start existing applications with a set of input parameters and to catch the completion notification plus the output generated by the application. Integrating scripts requires additional interfaces, e.g., for observing those parts of a business process which are con-trolled by these scripts. In addition, the workflow specification lan-guage must also be powerful enough to model the execution of scripts and to reflect their execution states. This observation leads to our first architectural requirement:

(1)A stepwise integration of workflow management functionality

into existing environments must be supported. This requires the integration and stepwise substitution of existing control flow implementations.

In case of our mail order business scenario, this means that the workflow management system must coexist with the script which checks the credit-worthiness of customers, checks the inventory database and finally initiates the delivery of the ordered items to the customer. The workflow management system will be responsible for the extensions of the workflow, i.e. for registering orders made on the web and for handling the payment by credit card.

2.2Seamless Integration of System Extensions

There are several components of workflow management sys-tems with highly workflow application dependent requirements on their functionality. These include worklist management, workflow monitoring, history management, and even interfaces to other workflow management systems. Consider, for example, the worklist manager. The major task of the worklist manager is to as-sign work items to actors based on a specific assignment strategy, also known as “role resolution”. Depending on the workflow ap-plication, assignment strategies can become very complex (e.g. principle of dual control, load balancing). Monitoring of workflows provides administrators with information about the cur-rent state of a workflow. The kind and the level of detail of this in-formation strongly depends on the workflow application. The same holds for the history of workflows, which can be considered as an aggregation of monitoring information. If dif ferent workflow man-agement systems are involved in the execution of a workflow, inter-faces between these systems are required. If the involved systems do not support a standard interface, if a common interface does not provide enough functionality, or if applications using the interface do not perform well enough, application specific interfaces have to be used.

It is easy to see that general purpose components for the above facilities will be complex to design and will increase the footprint of workflow management systems considerably. This is a major draw-back, as in most cases only a subset of their functionality is actually exploited. Hence, a workflow management system should provide means for implementing system extensions such that they can be seamlessly integrated into the system. This leads to our second ar-chitectural requirement:

(2) A workflow management system must facilitate the imple-

mentation and seamless integration of system extensions. Ap-plications must not suffer fr om runtime over head or lar ge sys-tem footprints caused by system extensions unless their func-tionality is actually exploited.

In the next section, we show how these requirements together with other, well known conventional requirements for workflow man-agement systems are reflected in the architecture of Mentor-lite. 3Mentor-Lite Architecture

In this section we present our approach to a light-weight and tailorable workflow management system. It is based on the Mentor workflow management system [24,25,42,43], but aims at a simpler architecture. The main goal is to provide only kernel functionality inside the workflow engine, and consider system components like history management and worklist management as extensions on top of the kernel. The key point to retain the light-weight nature is that these extensions are implemented as workflows themselves. An invocation interface for application programs as well as an in-terface for integrating scripts is provided. W e have coined our ap-proach Mentor-lite. W e first present the component architecture of Mentor-lite, followed by a brief introduction of the Mentor-lite workflow specification language, namely state and activity charts.

3.1Component Architecture

As shown in Figure 4, the basic building block of Mentor-lite is an interpreter for workflow specifications based on state charts. Two additional components, the communication manager (ComMgr) and the log manager (LogMgr) are closely integrated with the workflow interpreter. All three components together form the workflow engine, which in our case is identical to the workflow kernel.

Like in Mentor, Mentor-lite supports a protocol for a distributed execution of workflows. The communication manager is responsi-ble for sending and receiving synchronization messages between the engines. These messages contain information about locally raised events, updates of state chart variables and state information of the local engine [25]. When a synchronization message is re-ceived, the corresponding updates at the receiving site are per-formed. In order to guarantee a consistent global state even in pres-ence of site or network faults, we currently use the TP-Monitor Tuxedo [28, 35] for delivering the synchronization messages with-in queued transactions. In the near future, we plan to substitute the Tuxedo facilities by CORBA and object transaction services [8].

The log manager provides logging facilities and recovery mech-anisms. A separate workflow log is used at each site where a Men-tor-lite workflow engine is running. Databases like the workflow repository (i.e. a repository of workflow specifications) or the worklist database can be shared by Mentor-lite workflow engines at different sites.

Application programs and scripts are connected to the workflow engine by specific wrappers. Details of this interface will be presented in Section 4.

Workflow specifications are given in terms of state and activity charts, the specification language already used in Mentor. The in-terpreter performs a stepwise execution of the workflow specifica-tion according to its formal semantics. For each step, the activities to be performed by the step are determined and started. In contrast to Mentor, which initially included a code-generation phase, speci-fications in Mentor-lite are interpreted at runtime and can therefore be dynamically modified.

Application dependent facilities like worklist management,his-tory management and monitoring are implemented on top of the en-gine as state and activity charts. Hence, they are interpreted by the workflow interpreter just like any other workflow specification. A detailed example for implementing worklist management is given in [41], and for history management in [45].

Figure 4: The Mentor-lite architecture

3.2State and Activity Charts

In this section we briefly describe the formalism of state and ac-tivity charts [14, 15, 17] as used in Mentor–lite. This specification formalism has been adopted for the behavioral dimension of the UML industry standard [36]. State and activity charts comprise two dual views of a specification.

Activities reflect the functional decomposition of a system and denote the ”active” components of a specification; they correspond directly to the activities of a workflow. An activity chart specifies the data flow between activities, in the form of a directed graph with data items as arc annotations.

State charts capture the behavior of a system by specifying the control flow between activities. A state chart is essentially a finite state machine with a distinguished initial state and transitions driv-en by Event-Condition-Action rules (ECA rules). A transition from state X to state Y, annotated with an ECA rule of the form E[C]/A, fires if event E occurs and condition C holds. The ef fect is that state X is left, state Y is entered, and action A is executed. Conditions and actions are expressed in terms of variables, for example, those that are specified for the data flow in the corresponding activity chart. In addition, an action A can explicitly start an activity, expressed by st!(activity), and can generate an event E or set a condition C (e.g. fs!(C) sets the condition C to false). Each of the three components of an E[C]/A triple may be empty. Every state change in a state chart execution is viewed as a single step; thus, state changes induce a discrete time dimension.

Important additional features of state charts are nested states and orthogonal components. Nesting of states means that a state can itself contain an entire state chart. The semantics is that upon entering the higher-level state, the initial state of the embedded lower-level state chart is automatically entered, and upon leaving the higher-level state all embedded lower-level states are left. The capability for nesting states is especially useful for the refinement of specifications during the design process and for inserting prede-fined macros. Orthogonal components denote the parallel execu-tion of two state charts that are embedded in the same higher-level state (where the entire state chart can be viewed as a single top-level state). Both components enter their initial states simultaneously, and the transitions in the two components proceed in parallel, sub-ject to the preconditions for a transition to fire.4Integrating Applications with Mentor-lite In this section we discuss our approach on how to integrate ap-plication programs within Mentor-lite. W e distinguish between ap-plication programs which do not invoke or coordinate any other ap-plications and scripts which implement existing control flow and call application programs themselves.

4.1Interfaces to Application Programs

In most other workflow management systems, interfaces to ap-plication programs have to be completely implemented inside of application wrappers. In Mentor-lite, only basic communication in-terfaces are implemented by wrappers, e.g. using the distributed computing environment CORBA [27]. On top of these interfaces, protocols for complex interactions with application programs are specified in terms of state and activity charts. Being designed as a specification language for reactive systems, state and activity charts are particularly suited to serve this purpose. As a further ad-vantage, we use the same language for specifying workflows and interface protocols. This way, interface protocols can be specified by workflow designers without the need to use other programming environments, e.g. for implementing interface protocols in C.

In Mentor-lite, each activity defined in an activity chart is tagged with its invocation method, e.g. remote procedure call (RPC), operating system call, or CORBA call. When interpreting the workflow specification, for each activity to be executed, a func-tion implementing the invocation of the activity is called. As an ex-ample, we show the Mentor-lite CORBA interface for controlling application programs. It is realized using Orbix [18], a CORBA im-plementation. For each application program, a proxy object identi-fying its wrapper has to be created. The corresponding function looks like this:

createProxy(const char* AppName)

{ ... p = _bind(:WrapperAppName) ; ... }

The _bind() statement creates the proxy object for the wrapper of the application AppName in the workflow engine’s address space. Further, it returns a handle (p) to this object.

The application wrapper must enable the workflow engine to start and stop the application program and to exchange information with the application. For example, the application programs should be able to raise events and set state chart variables and, in turn, the

Figure 5b: Implementation of an application specific wrapper

interface Wrapper {

void start();void stop();

short get(in string data, out string results);short put(in string data);}

Figure 5a: Generic interface definition for application wrappers in IDL class WrapperApp: public WrapperBOAImpl {

void start(CORBA::Environment &IT_env) { ... system(App); ...};void stop(CORBA::Environment &IT_env) { ... };

CORBA::Short get(const char* data, char *& results, CORBA::Environment &IT_env) { ... };CORBA::Short put(const char* data, CORBA::Environment &IT_env) { ... };}

application programs should be able to receive updates of state chart variables.

The generic interface of application wrappers is shown in Figure 5a . Four functions constitute the interface:

?The start() function invokes the application. In the example im -plementation in Figure 5b the application “App” is started by issuing an operating system call.

?The stop() function for terminating an application.

?The put() function to transfer information from the WF engine

to the application.

?The get() function to transfer information from the application

to the WF engine.

The WF engine can access all functions of the wrapper imple-mentation by using the handle returned by the _bind() call. For ex -ample, the WF engine can ask the wrapper to start the application App by calling p->start(). While the interface definition is generic,its implementation is different for each application, i.e. there is a different implementation class of the wrapper interface for differ-ent applications. This of course requires the application program to offer the desired functionality in its application programming inter -face (API).

As mentioned above, this set of functions is used as a building block for implementing complex invocation and interaction proto -cols between the Mentor-lite kernel and application programs in terms of state and activity charts. Generic state charts, e.g. for enab -ling an actor to start, stop, suspend and resume an activity , form a library of invocation protocols which can be used in each workflow specification.

4.2Interfaces to Scripts

The approach of providing only a simple wrapper and specify -ing complex interface protocols in terms of state and activity charts is also used for integrating existing scripts. A Mentor-lite library contains state and activity chart templates which model generic steps for integrating existing scripts, e.g. templates for modelling the interception of application calls issued by scripts. This transfers the responsibility for invoking applications to Mentor-lite and en-ables the extension of existing control flow without reimplement-ing everything from scratch. Our mail order business scenario will serve as an example to illustrate different steps of the integration.In the first step, we define a state and activity chart for each script. The activity chart consists of a single activity representing the script, the state chart consists of a corresponding state and an initial transition which starts the activity . In order to link the activity to the script, a simple wrapper providing an invocation interface is required. T ogether , the state and activity chart specify a workflow consisting only of the existing script. Given this simple form of in -tegration, we have three options to continue:

(1)The workflow specification is extended by inserting new ac-tivities and the corresponding control flow. In this case, the

script is called as part of an extended workflow in the same way as one atomic activity and remains unchanged.

(2)Calls to application programs issued by the script are rerouted

to the workflow management system kernel by intercepting the application invocation. This way, the script is decoupled from the activities it invokes. The activities can be substituted by other ones, even by complete subworkflows. The new ac-tivities and subworkflows are invoked in place of the original activities. Using dummy activities that implement a null action makes parts of the script inef fective. This option provides for an incremental substitution of scripts by state and activity charts.

(3)Scripts are substituted by state and activity charts, i.e., com-pletely rewritten from scratch. This is the most comprehen-sive, but also the most expensive approach.

In the following, we discuss how options (1) and (2) are used to ex -tend an existing control flow implementation in our mail order business scenario. Using option (3) usually causes too much over -head and is disregarded in this paper.

As described in Section 2.1, our mail order business wants to ex -ploit the Internet. Customers should be able to place orders via the internet, payment will be done through credit cards. This extension requires additional activities to be invoked, and existing activities to be substituted by new ones.

The new workflow is specified in terms of state and activity charts, still making use of the existing script which registers incom -ing orders in a database, checks the credit-worthiness of the cus-tomer, checks an inventory database to see if the ordered items are in stock, and prints an invoice. Figure 6 shows the activity chart,with the script represented by activity Script. There are four addi -tional activities, namely the WebOrder activity, the ElectronicBil-ling activity, the SendResults activity, and the CheckCreditCard activity. WebOrder and ElectronicBilling extend the original workflow according to option (1). WebOr der inserts orders placed by using a web-interface into the database, such that they are avail -able to Script. ElectronicBilling performs the payment by credit card. Activity SendResults will be explained later . The forth activi -ty, CheckCreditCard , substitutes the original check of the custom -er’s credit-worthiness. Its integration requires that the original call to the credit-worthiness check by the script is intercepted and redi -rected towards the credit card check. The handling of the credit card check should be controlled by Mentor-lite. This extends the workflow according to option (2).

In Figure 7, the corresponding state chart is shown. For better readability, we use the suffix “_S ” for all state identifiers.Whenever a web order arrives the order is placed in the order -data-base by activity WebOrder , which is started in the initial transition to state WebOrder_S . The existing script, i.e., activity Script is started after the activity WebOrder is finished, i.e., when the condi -tion WO_OK evaluates to true and the nested state Script_S is en-tered. The nesting of this state is necessary to conceptually split the

Script

Web-Order Electronic-Billing

CheckCredit-Card

WebOrderBusiness_AC Send-Results

Figure 6: The activity chart for the web order business extension

script into two parts. The first part, represented by state ScriptA _S,corresponds to the existing control flow before issuing the check for credit-worthiness, while the state ScriptB_S is entered after the check is done. Instead of calling the original check for credit-wor -thiness, the activity CheckCreditCard is invoked when the transi-tion to state CheckCreditCard_S fires. After the script is finished,indicated by condition Script_DONE , activity ElectronicBilling is started.

Note that the script, represented by activity Script , is not modi -fied at all, i.e. the code of the script remains unchanged. But one of its calls to application programs, the credit-worthiness check, is in -tercepted and redirected to the workflow engine. T o show how this is implemented, we have to go into more detail about invocations of wrappers and their communication with the workflow engine when executing the part of the state chart which corresponds to the nested state Script_S . Figure 8 shows actions performed by the workflow engine, the script and its wrapper , a substitution program (stub) for the credit-worthiness check, and the new activity CheckCredit-Card. On the left hand side, the substates of state Script_S and the corresponding transitions are shown. On the right hand side, in-vocations of wrappers and the stub as well as the communication of these wrappers and the stub with the workflow engine is shown.When entering the state Script_S, the initial transition to the first substate ScriptA_S fires, i.e. the activity Script is started. Since all activities that represent application programs are invoked via their wrappers, the start of activity Script results in the execution of the wrapper of the script. The wrapper will start the script which pro -ceeds to the call of the credit-worthiness check application. The original behavior was to issue this call and to wait for its comple-tion. Now the call is intercepted by the stub for the credit-worthi-ness check. It sets the condition START_CheckCreditCard to true and passes the calling information for the credit-worthiness check to the workflow engine. Because we want to substitute the credit-worthiness check by a credit card check, the workflow engine now invokes the wrapper for the application program that checks credit cards by starting activity CheckCreditCard . After the correspond -ing application program has successfully finished, its wrapper will set

dition variable and the return parameters of the credit card check to the workflow engine. When the workflow engine receives the con -dition CheckCredit Card_DONE , the transition from the state CheckCreditCard to state ScriptB_S fires, and activity SendResults is started. This activity is necessary to relay the return values through the workflow engine to the stub, which in turn relays them to the script. Hence, the script does not notice a dif ference between the execution of the check for credit-worthiness and the check of the credit card. It proceeds with the rest of its code. Finally, the script will finish and its wrapper will set the condition Script_DONE to true.

The example has shown how the integration of scripts with workflows specified in Mentor -lite is performed. Note that the in -terfaces between the workflow engine and wrappers for application programs as defined in Section 4.1 are suf ficient to implement the integration. Only a simple stub for implementing the redirection of a call to an existing application program is additionally required.This stub is generic and can be used for redirecting other calls as well. The protocol for using the stub was specified in terms of state and activity charts, showing the feasibility of using state and activi -ty charts to integrate existing control flow implementation.

5Conclusions

In this paper , we have investigated two major obstacles for inte -grating current workflow management systems into environments with already existing computerized business processes:

?Current workflow management systems are best suited for im -plementing all control flow from scratch. They provide only limited means for interacting with existing computerized busi -ness processes.

?Components like worklist management and history manage-ment are usually tailored for specific application scenarios. For other scenarios, they either cause too much overhead or lack re -quired functionality.

In principle, these two problem areas are orthogonal issues. How -ever, we believe that an extensible light-weight workflow manage -ment system is a crucial architectural asset for both directions. W e Figure 7: The state chart for the web order business extension

Protocol between workflow engine and the script

WF engine Stub for credit-worthiness check

Script (wrapper)

CheckCreditCard ap-plication program (wrapper)

...

and communication facilities, whereas solutions to the above prob -lems are implemented in the workflow specification language, i.e.,as workflows themselves. We have shown that state and activity charts, our method of choice for specifying workflows, are well suited for implementing specific protocols to integrate existing im -plementations of control flow in an incremental manner . Optional administration facilities can be specified on top of the kernel as sub -workflows. Using this approach, functionality implemented in the kernel, e.g., distributed execution, reliable and fault tolerant execu -tion, encryption etc., is automatically available to all extensions.This allows even a decentralized execution of role resolution strate -gies for work items or a decentralized history management without additional implementation effort.

In the future, we plan to extend our prototype implementation to get further proofs of concept. We will investigate three different areas. Application programs with interfaces to distributed comput -ing environments like CORBA and DCOM enable workflows to use specific application facilities, far beyond a simple https://www.wendangku.net/doc/bd12975318.html,ing these facilities requires extended wrapping functionality on top of the distributed computing environment. But instead of im-plementing such extended wrappers in a programming language like C, we will use state and activity charts. Only the basic Mentor -lite kernel interface to the distributed programming environment will be implemented in C. In the second area, we will implement libraries of optional administration facilities such as worklist and history management. We plan to investigate the feasibility of our approach for even more demanding system components such as alerting mechanisms based on time constraints and interfaces to other workflow management systems. Finally , we will investigate the impact of our architectural decisions on the system performance. Our aim is to define simple but realistic benchmarks and to apply them for comparing Mentor -lite with other workflow management systems. A first proposal is presented in [44].

6References

[1]G. Alonso, D. Agrawal, A. El Abbadi, C. Mohan, Functional -ity and Limitations of Current Workflow Management Systems,IEEE Expert, V ol. 12, No. 5, 1997

[2] G. Alonso, C. Hagen, Geo-Opera: Workflow Concepts for Spatial Processes, in: M. Scholl, A. V oisard (ed.): Advances in Spa -tial Databases, Lecture Notes in Computer Science, Vol. 1262,Springer, 1997

[3]G. Alonso, C. Hagen, H. J. Schek, M. T resch, T owards a Plat -form for Distributed Application Development in [9]

[4] D. Barbara, S. Mehrotra, M. Rusinkiewicz, INCAs: Manag-ing Dynamic Workflows in Distributed Environments, Journal of Database Management, Special Issue on Multidatabases, V ol. 7,No. 1, 1996

[5] M. J. Carey, D. J. DeWitt, Of Objects and Databases: A De-cade of Turmoil, Proc. of Int’l Conf. on Very Large Data Bases (VLDB), Bombay, India, 1996

[6]T. Cai, P . A. Gloor , S. Nog, DartFlow: A W orkflow Manage -ment System on the Web using Transportable Agents, Technical Report PCS-TR96-283, Dartmouth Collage, 1996

[7] A. Cichocki, A. Helal, M. Rusinkiewicz, D. Woelk, Work-flow and Process Automation - Concepts and T echnology , Kluwer Academic Publishers, 1998

[8]CORBA Services Available Electronically,https://www.wendangku.net/doc/bd12975318.html,/corba/csindx.htm

[9] A. Dogac, L. Kalinichenko, M. T amer Ozsu, A. Sheth (Eds.),Workflow Management Systems and Interoperability, NATO Ad-vanced Study Institute, Springer, 1998

[10]J. Eder, H. Groiss, W. Liebhart, The W orkflow Management System Panta Rhei, in [9]

[11] D. Georgakopoulos, M. Hornick, A. Sheth, An Overview of Workflow Management: From Process Modeling to W orkflow Au-tomation Infrastructure, Distributed and Parallel Databases, V ol. 3, No. 2 , 1995

[12]R. Günth?r, S. Jablonski, T ransaction-Based Application In-tegration in Workflow Management Systems, Proc. of the Int’l Conf. on Database and Expert Systems Applications (DEXA), Zu-rich, Switzerland, 1996

[13]R. Grimes, Professional DCOM Programming, WROX Press, Birmingham, 1997

[14] D. Harel, State Charts: A V isual Formalism for Complex Sys-tems, Science of Computer Programming, Vol. 8, 1987, pp. 231-274

[15] D. Harel et. al, Statemate: A Working Environment for the Development of Complex Reactive Systems, IEEE Transactions on Software Engineering, Vol. 16, No. 4, 1990

[16]J. Hammer, H. Garcia-Molina, S. Nestorov, R. Yerneni, M. Breunig, V. Vassalos, Template-Based W rappers in the TSIMMIS System, Proc. of ACM SIGMOD Conf. (Demonstration), T ucson, Arizona, 1997

[17] D. Harel, A. Naamad. The ST ATEMATE Semantics of State Charts, Technical Report, i-Logix Inc., October 1995

[18]Manuals of Orbix 2.2, IONA Technologies PLC, 1997

[19] S. Jablonski, MOBILE: A Modular W orkflow Model and Ar-chitecture, Proc. of Int’l W orking Conf. on Dynamic Modelling and Information Systems, Nordwijkerhout, Netherlands, 1994 [20] S. Jablonski, C. Bussler, Workflow Management, Modeling Concepts, Architecture, and Implementation, International Thom-son Computer Press, 1996

[21]O. Kapitskaia, A. Tomasic, P. Valduriez, Dealing with Dis-crepancies in W rapper Functionality, 13éme Journées de Bases de Données Avancées, Grenoble, France, 1997

[22] C. Li, R. Yerneni, V. Vassalos, H. Garcia-Molina, Y, Papa-konstantinou, J. Ullmann, M. V aliveti, Capability Based Mediation in TSIMMIS, Proc. of ACM SIGMOD Conf. (Demonstration), Seattle, Washington, 1998

[23]J. A. Miller, D. Palaniswami, A. P. Sheth, K. Kochut, H. Singh: WebWork: METEOR2’s Web-Based Workflow Manage-ment System, Journal of Intelligent Information Systems, V ol. 10, No. 2, 1998

[24]P. Muth, D. W odtke, J. W eissenfels, G. W eikum, A. Kotz Dit-trich, Enterprise-wide Workflow Management based on State and Activity Charts, in [9]

[25]P. Muth, D. Wodtke, J. Weissenfels, A. Kotz Dittrich, G. Weikum, From Centralized W orkflow Specification to Distributed Workflow Execution, Journal of Intelligent Information Systems, Special Issue on Workflow Management, V ol. 10, No. 2, 1998 [26]H. Naacke, G. Gardarin, A. Tomasic, Leveraging Mediator Cost Models with Heterogeneous Data Sources, Proc. of Int’l Conf. on Data Engineering (ICDE), Orlando, Florida, 1998[27]OMG, The Common Object Request Broker: Architecture and Specification, Rev. 2.0, T echnical Report, Object Management Group, 1995

[28] F. Primatesta, TUXEDO, An Open Approach to OL TP. Pren-tice Hall, 1994

[29] B. Reinwald, C. Mohan, Structured Workflow Management with Lotus Release 4, Proc. of IEEE Computer Society Int’l Conf., Santa Clara, California, 1996

[30]M. T. Roth, P. Schwarz, Don’t Scrap It, Wrap It! A Wrapper Architecture for Legacy Data Sources, Proc. of Int’l Conf. on V ery Large Data Bases (VLDB), Athens, Greece, 1997

[31] A. Sheth (ed.), Proceedings of NSF Workshop on Workflow and Process Automation in Information Systems, Athens, Geor gia, 1996,

https://www.wendangku.net/doc/bd12975318.html,/activities/NSF-workflow/proc_cover.html [32]H. Schuster, S. Jablonski, P. Heinl, C. Bussler, A General Framework for the Execution of Heterogeneous Programs in W ork-flow Management Systems, Proc. of Int’l Conf. on Cooperative In-formation Systems (CoopIS), Brussels, Belgium, 1996

[33] A. Sheth, K. J. Kochut, W orkflow Applications to Research Agenda: Scalable and Dynamic W ork Coordination and Collabora-tion Systems, in [9]

[34]Staffware Global White Paper, Staffware PLC, 1997, https://www.wendangku.net/doc/bd12975318.html,/home/whitepapers/data/globalwp.htm

[35]Tuxedo System 5, System Documentation, Novell, 1994

[36] Unified Modeling Language (UML) V ersion 1.1, https://www.wendangku.net/doc/bd12975318.html,/uml/documentation.html

[37]G. V ossen, J. Becker (Eds.), Business Process Modelling and Workflow Management, Models, Methods, and T ools, Internation-al Thomson Publishing (in German), 1996

[38]G. V ossen, M. Weske, The WASA Approach to Workflow Management for Scientific Applications, in [9]

[39]Workflow Management Coalition, https://www.wendangku.net/doc/bd12975318.html,

[40]G. W iederhold, Mediators in the Architecture of Future Infor-mation Systems, IEEE Computer Magazine, March 1992 [41]J. W eissenfels, P. Muth, G. W eikum, Flexible W orklist Man-agement in a Light-Weight Workflow Management System, Proc. of EDBT W orkshop on W orkflow Management Systems, V alencia, Spain, 1998

[42]J. W eissenfels, D. W odtke, G. W eikum, A. Kotz Dittrich, The MENTOR Architecture for Enterprise-wide Workflow Manage-ment. In: [31]

[43] D. W odtke, J. W eissenfels, G. W eikum, A. Kotz Dittrich, The MENTOR Project: Steps Towards Enterprise-Wide Workflow Management, Proc. of Int’l Conf. on Data Engineering (ICDE), New Orleans, Louisiana, 1996

[44]M. Gillmann, P. Muth, G. Weikum, J. Weissenfels, Bench-marking of W orkflow Management Systems (in German), Proc. of Datenbanksysteme in Büro, Technik und Wissenschaft (BTW), Freiburg, Germany, 1999

[45]P. Muth, J. W eissenfels, M. Gillmann, G. W eikum, W orkflow History Management in Virtual Enterprises using a Light–Weight Workflow Management System, Proc. of Int’l Workshop on Re-search Issues in Data Engineering (RIDE), Sydney, Australia, 1999

品茗安全计算软件操作

问题：1、软件打开时，跳出对话框，failed to set data for. 这种情况可能是软件没装好。部分文件缺失，建议重新安装一遍试试看。 2、在软件中无法操作，对梁不设置对拉螺栓对拉螺栓是可以设置的。在梁侧模板计算中设置。如果不设置对拉螺栓，需要在表中，将“距梁底距离”中的两个数据输入为“0”和“梁高-板厚”。 3、梁底支撑小横杆根数及间距无法设置当梁底有附加立杆时，该参数受软件控制，无法设置。4、梁底增加支撑的间距无法设置不是很明确，梁底增加支撑如果是指附加的立杆，可以在表中选择自定义的方式。如果指的是梁底的支撑小梁根数（间距），小梁的间距是根据根数和梁宽进行均分计算的。 5、荷载参数里施工人员设备荷载和振捣荷载只需要计算一个就行了。（参考规范JGJ162-2008）答：梁受力支撑计算施工人员设备荷载，板受力支撑计算振

捣荷载，如果梁和板都受力两个都需要计算。 6、悬挑脚手架计算中，“拉绳与支撑杆”设置中“共点”与“平行”有什么区别？答：平行和共点，对于单道拉绳或支撑来说，没什么大的区别，它们的区别是在于，“平行”时输入的是拉绳（支撑）与水平面的夹角。共点时输入的是这个夹角所造成的两个直角边的长度，软件通过这两个直角边长来计算夹角。如果是多道支撑或拉结，就比较明显了。平行是多道支撑或拉结近似平行线。共点是支撑或拉结近似节点集中一点。 7、工地承重架和脚手架的扣件，检测中，直角扣件、旋转扣件，抗破坏和抗滑不合格，请问在品茗安全计算中，怎么进行复算啊？答：对于扣件抗滑力检测不合格的情况，在相关部门许可的情况下，可以降低承载力使用。或者增加双扣件进行支撑。或者直接清除不合格材料，改用检测合格的材料进行支撑。如果是属于扣件抗破坏性能检验不合格，则需要更换扣件材料。或者降低允许承载力，加密支撑杆件等方式进行使用。以上措施仅限于材料不合格在允许范围内或者相关部门允许的情况下使用，如果不允许使用，建议更换检测合格的材料使用，毕竟这也是关系到人民生命财产安全的大事。

泛微oaecology二次开发实例开发完整说明讲解学习

二次开发培训文档一、ECOLOGY系统框架结构 1、主要的程序结构 Ecology Classbean 存放编译后的CLASS文件 js 系统中使用的JA V ASCRIPT和VBSCRIPT脚本 Css 系统中JSP页面使用的样式 Images Images_face Images_frame 系统中使用的图片的存放目录 Crm Workflow 该功能分文件夹存放每个功能的文件 WEB-INF Prop 系统配置文件存放 Service 系统的接口配置文件的存放二、说明一个JSP页面，一个JA V A程序的基本组成，如何阅读JSP页面 1、一个jsp页面通常需要包含什么内容 2、如何阅读一个JSP页面由于ECOLOGY系统支持多语言，因此在JSP页面上一般不出现中文，全部使用标签的形式来显示中文：比如：在IE上显示“姓名”那么在JSP页面中将通过 <%=SystemEnv.getHtmlLabelName(413,user.getLanguage())%>这样的形式来表示，其中的数字413就是表示姓名，同时可以通过“select labelname from htmllabelinfo where indexid=413 and languageid=7”来获取到“姓名”这个显示名称，其中 languageid=7表示中文显示名称,languageid=8表示英文显示名称. delete from HtmlLabelIndex where id=81249 delete from HtmlLabelInfo where indexid=81249 INSERT INTO HtmlLabelIndex values(81249,'选择范围') INSERT INTO HtmlLabelInfo VALUES(81249,'选择范围',7) INSERT INTO HtmlLabelInfo VALUES(81249,'Range of choice',8) INSERT INTO HtmlLabelInfo VALUES(81249,'選擇範圍',9) 3、JA V A程序的基本组成在ECOLOGY中开发JA V A程序建议继承weaver.general. BaseBean，在BaseBean 中主要封装了两个方法：写日志文件，获取配置文件中的参数值。 public String getPropValue(String fname , String key) public void writeLog(Object obj)

品茗安全计算软件新手入门教程1梁侧模版

品茗安全计算软件新手入门教程—梁侧模版参考规范下载 1、《建筑施工模板安全技术规范》JGJ162-2008 2、《建筑结构荷载规范》GB50009-2012 3、《钢结构设计规范》GB50017-2003 4、《混凝土结构设计规范》GB 50010-2010 5、《混凝土结构工程施工规范》GB50666-2011 6、建筑施工计算手册(第二版) 基本知识

上翻梁部位名称

梁侧模板参数参数解析 ①混凝土梁工程属性计算书显示形式：分为各侧模计算过程全部显示及各侧模计算过程汇总显示；当梁侧有上翻及下挂部分时，软件会把每侧上翻及下挂分别计算，共四大计算部分，其计算原理相

同，如果全部显示，计算书内容过多；生成计算书时，可以以汇总形式展示。同时为了帮助客户更好的理解，软件也把全部显示提供给大家选择；可以根据不同需要进行选择。新浇混凝土梁名称：一般以梁所在的轴线及梁的名称进行命名；梁板结构情况：共十种类型；根据实际工况进行选择。混凝土梁结构类型新浇混凝土梁截面尺寸【宽×高】：根据梁实际截面尺寸进行填写。新浇混凝土梁计算跨度：根据梁实际跨度计算。 ②支架体系设计小梁布置方式：分为水平向布置及竖直向布置两种；根据现场实际工况进行选择。小/主梁间距：按中心到中心实际间距进行填写。

梁侧系数主梁合并根数：根据现场实际工况进行选择。主梁受力不均匀系数：采用双主梁时，考虑材料、施工质量等因素，主梁很难实现均匀受力，产生受力不均匀系数。小/主梁最大悬挑长度：软件可根据梁计算跨度及主梁/小梁间距进行自动计算。软件默认梁侧悬挑长度相同，如果不相同用户可根据实际情况进行填写，不要勾选自定义。小/主梁计算方式：根据主梁/对拉螺栓间距及所用材料长度相对关系确定跨数；如主梁间距600mm，小梁长度2000mm，就可以选择3等连续梁进行计算。对拉螺栓水平间距：小梁布置方式为水平向布置其间距和主梁间距相同用户无需修改；小梁布置方式为竖直向布置其间距根据实际情况进行输入。结构表面的要求：主要包含两个类型，结构表面隐藏和结构表面外露两种。根据现场实际工况选择，JGJ162-2008第4.4.1条及GB50666-2011第4.3.9条规定：选择外露时对结构变形验算要求较高允许值为计算跨度的1/400,选择隐藏时1/250。

WorkflowRuntime 使用

1WorkflowRuntime 名称空间:System.Workflow.Runtime.WorkflowRuntime 文件:system.workflow.runtime.dll 在工作流的运行环境（宿主）中,为工作流提供运行的引擎 1．WorkflowRuntime在宿主中以自已独立的线程运行例 2．WorkflowRuntime可以加载多个工作流实例，每个工作流实例在WorkflowRuntime有独立的线程 3.同一宿主可可以实例化多个引擎，他们可以同时工作 2引擎的状态管理 3使用引擎创建实例 3.1使用工作流类创建实例

3.2使用XmlReader创建实例 3.3用自定义的GUID创建实例

3.4创建实例时指定参数可以在用引擎创建一个工作流实例时，用System.Collections.Generic.Dictionary集合传一组键值对，

4从引擎中得到工作流实例4.1得到内存中所有工作流实例的集合 4.2得到指定GUID的工作流实例

5引擎事件5.1与引擎状态相关的事件事件类型:EventHandler 事件参数:e.IsStarted //是否启动 5.2与实例持久化相关的事件事件类型:EventHandler 事件参数: e.WorkflowInstance //工作流实例

5.3与实例运行相关的事件事件类型:EventHandler 事件参数: e.WorkflowInstance //工作流实例 5.4引擎中实例完成后WorkflowCompleted 事件类型:EventHandler 事件参数:e.WorkflowInstance 工作流实例 e.WorkflowDefinition //类型为https://www.wendangku.net/doc/bd12975318.html,ponentModel.Activity,可以用该参数得到实例类型， //在该事件中无法使用 e.WorkflowInstance.GetWorkflowDefinition().GetType()得到实例类型 e.OutputParameters //用参数方式与实例的属性进行通信

深入浅出Oracle_EBS之Workflow实例详解

Ora E-B O RA Wor Author: MSN: Creation Last Up Docume Version Approv ver 2> ERP 最ESS S U 核心应w 黄建华 huajhua@ho April 17, 200November 1 践 Copy Number _____

Workflow File Ref: 深入浅出Oracle EBS之Workflow实例详解.docx (v. DRAFT 1A ) Document Control ii Document Control Change Record Date Author Version Change Reference 17-Apr-07 Jianhua.Huang Draft 1a No Previous Document Reviewers Name Position Distribution Copy No. Name Location 1Library Master Project Library 2Project Manager 3 4 Note To Holders: If you receive an electronic copy of this document and print it out, please write your name on the equivalent of the cover page, for document control purposes. If you receive a hard copy of this document, please write your name on the front cover, for document control purposes.

品茗安全计算软件操作

品茗安全计算软件操作问题:1、软件打开时，跳出对话框，failed to set data for. 这种情况可能是软件没装好。部分文件缺失，建议重新安装一遍试试看。 2、在软件中无法操作，对梁不设置对拉螺栓对拉螺栓是可以设置的。在梁侧模板计算中设置。如果不设置对拉螺栓，需要在表中，将“距梁底距离”中的两个数据输入为“0”和“梁高-板厚”。 3、梁底支撑小横杆根数及间距无法设置当梁底有附加立杆时，该参数受软件控制，无法设置。 4、梁底增加支撑的间距无法设置不是很明确，梁底增加支撑如果是指附加的立杆，可以在表中选择自定义的方式。如果指的是梁底的支撑小梁根数(间距)，小梁的间距是根据根数和梁宽进行均分计算的。 5、荷载参数里施工人员设备荷载和振捣荷载只需要计算一个就行了。(参考规范JGJ162-2008) 答:梁受力支撑计算施工人员设备荷载，板受力支撑计算振捣荷载，如果梁和板都受力两个都需要计算。 6、悬挑脚手架计算中，“拉绳与支撑杆”设置中“共点”与“平行”有什么区别, 答:平行和共点，对于单道拉绳或支撑来说，没什么大的区别，它们的区别是在于，“平行”时输入的是拉绳(支撑)与水平面的夹角。共点时输入的是这个夹角所造成的两个直角边的长度，软件通过这两个直角边长来计算夹角。

如果是多道支撑或拉结，就比较明显了。平行是多道支撑或拉结近似平行线。共点是支撑或拉结近似节点集中一点。 7、工地承重架和脚手架的扣件，检测中，直角扣件、旋转扣件，抗破坏和抗滑不合格，请问在品茗安全计算中，怎么进行复算啊, 答:对于扣件抗滑力检测不合格的情况，在相关部门许可的情况下，可以降低承载力使用。或者增加双扣件进行支撑。或者直接清除不合格材料，改用检测合格的材料进行支撑。如果是属于扣件抗破坏性能检验不合格，则需要更换扣件材料。或者降低允许承载力，加密支撑杆件等方式进行使用。以上措施仅限于材料不合格在允许范围内或者相关部门允许的情况下使用，如果不允许使用，建议更换检测合格的材料使用，毕竟这也是关系到人民生命财产安全的大事。安全计算软件常见问题整理 1、在钢管落地脚手架计算中，地基参数中地基底面扩展面积如何设置, 答:地基底面扩展面积就是立杆下垫块的平均面积，有些客户采用的都是立杆下垫块长的钢板(槽钢)的方法，那么就可以用此块垫块的总面积除以垫块上立杆的数量即可得到。 2、风荷载体型系数的设置答:风荷载体型系数主要是考虑构筑物的迎风面积和挡风面积的比例关系，如果有安全网，要考虑安全网对体型系数的影响。 3、在钢管落地脚手架计算中，双立杆计算方法选择中按要求设计和按双立杆均匀受力有什么区别, 答:按照构造要求设置双立杆时，只将双立杆作为构造措施，副立杆不参与计算，起到加强安全性的作同时考虑两根立杆的受力，此时，副立杆参与受力计算。 4、脚手架配件用量如何计算,

INFORMATICA关于WORKFLOW Manager系统的元数据解析

INFORMATICA关于WORKFLOW Manager系统的元数据解析 INFORMATICA关于WORKFLOW Manager系统的元数据解析关键词：INFORMATICA,WOR Manager,元数据 informaica是一个很强大的ETL工具。其WORKFLOW MANAGER负责对ETL调度流程进行设计与管理和执行！informatica在在资料库中提供以下表来存储调动流程的相关信息。以便WORKFLOW MANAGER对用户所设计的调动流程进行管理和执行。 opb_wflow_dep:描述workflow执行步骤相关信息和每个步骤执行的条件信息 opb_wflow_dep_run：描述workflow执行步骤运行时相关信息 opb_wflow_expr ：描述workflow中相关的表达式或条件的相关信息 opb_wflow_perval：描述workflow可持续性变量相关信息opb_wflow_run:描述workflow运行日志相关信息 opb_wflow_var:描述workflow变量相关信息

opb_task:描述任务对象的基本信息 opb_task_attr:描述任务对象相关的属性的信息 opb_task_inst:描述任务对象实例的基本信息 opb_task_inst_run:描述任务对象实例运行日志相关信息opb_task_val_list:描述任务对象实例中command信息WORKFLOW MANAGER系统中常用的有这几个模块，Command模块， Session模块， Waiting_Event模块， Raising_Event模块， Assignment模块， Worklet模块 WORKFLOW MANAGER系统中上述的这些模块统称为任务(Task).如果你对一个模块进行了复制后新的模块就称作该任务的任务实例（Task_Inst）. WORKFLOW MANAGER系统中Worklet模块可以有其他非Worklet模块组成。在WORKFLOW MANAGER系统中一个工资流被称作Workflow,Workflow由各种任务模块组合而成。同时一个Workflow也是一个任务。以下是WORKFLOW 元数据表的详细说明， -----------------------------------------------------------------------

品茗安全计算软件操作文件

问题：1、软件打开时,跳出对话框,failed to set data for. 这种情况可能是软件没装好.部分文件缺失,建议重新安装一遍试试看. 2、在软件中无法操作,对梁不设置对拉螺栓对拉螺栓是可以设置地.在梁侧模板计算中设置.如果不设置对拉螺栓,需要在表中,将“距梁底距离”中地两个数据输入为“0”和“梁高-板厚”. 3、梁底支撑小横杆根数及间距无法设置当梁底有附加立杆时,该参数受软件控制,无法设置. 4、梁底增加支撑地间距无法设置不是很明确,梁底增加支撑如果是指附加地立杆,可以在表中选择自定义地方式. 如果指地是梁底地支撑小梁根数（间距）,小梁地间距是根据根数和梁宽进行均分计算地. 5、荷载参数里施工人员设备荷载和振捣荷载只需要计算一个就行了.（参考规范JGJ162-2008）答：梁受力支撑计算施工人员设备荷载,板受力支撑计算振捣

荷载,如果梁和板都受力两个都需要计算. 6、悬挑脚手架计算中,“拉绳与支撑杆”设置中“共点”与“平行”有什么区别？答：平行和共点,对于单道拉绳或支撑来说,没什么大地区别,它们地区别是在于,“平行”时输入地是拉绳（支撑）与水平面地夹角.共点时输入地是这个夹角所造成地两个直角边地长度,软件通过这两个直角边长来计算夹角.如果是多道支撑或拉结,就比较明显了.平行是多道支撑或拉结近似平行线.共点是支撑或拉结近似节点集中一点. 7、工地承重架和脚手架地扣件,检测中,直角扣件、旋转扣件,抗破坏和抗滑不合格,请问在品茗安全计算中,怎么进行复算啊？答：对于扣件抗滑力检测不合格地情况,在相关部门许可地情况下,可以降低承载力使用.或者增加双扣件进行支撑.或者直接清除不合格材料,改用检测合格地材料进行支撑. 如果是属于扣件抗破坏性能检验不合格,则需要更换扣件材料.或者降低允许承载力,加密支撑杆件等方式进行使用. 以上措施仅限于材料不合格在允许范围内或者相关部门允许地情况下使用,如果不允许使用,建议更换检测合格地材料使用,毕竟这也是关系到人民生命财产安全地大事.

(转载)和我一起学Windows Workflow Foundation(1)-----创建和调试一个WF实例)

导航 ?首页 ?日志 ?相册 ?音乐 ?收藏 ?博友 ?关于我日志小翼程序员就像男人,语言就像女人,每个男人都想要很多女人,却很少有男人能真正了解一个女人,因为男人总是朝三暮四,而女人每天都在变,甚至有些是经过变性和整容的。加博友关注他最新日志 ?飘荡 ?游走... ?过客.. ?...记录 ?拯救... ?迷失? 该作者的其他文章

博主推荐相关日志随机阅读首页推荐 ?俄监狱举办选美大赛 ?街拍“大宋”美女游郑州 ?韩女星遗书曝被迫卖身 ?我在美国野外露营装备 ?为毛泽东看病的六大御医 ?3种易被小三勾引的男人更多>> 对“推广广告”提建议应届毕业生必看（转）（转载）和我一起学Windows Workflow Foundation(2) 让WF通过参数接收数据（转载）和我一起学Windows Workflow Foundation(1)-----创建和调试一个WF实例）工作流研究2009-03-13 12:09:13 阅读196 评论0 字号：大中小订阅今天开始，我打算开始学习WWF，从网上搜索到了部分相关资料，也找到了一些文档和实验。但是，资料以英文的占多数，所以，在学习起来似乎比较吃力，不过相信我能坚持下来，顺便提高点英语阅读能力，不过本人英文水平实在是差，解释的不到位或错误的地方请大家谅解（千万别笑话我，哈哈）。毕竟我也是从空白开始学习WWF，让我们一起进步。首先，我们需要安装WinFX（下载）和Visual Studio 2005 extensions for .NET Framework 3.0 (Windows Workflow Foundation)。这是我们必备的开发组件。这些例子和教程是从微软的labs上下载到的，分为10个部分。先来学最基础的第一部分先：）第一部分的目的这个试验的目的是介绍Windows Workflow Foundation的工作流概念的关键点完成了这个试验以后，我们可以学习到: ·使用Visual Studio 2005 为WWF设计顺序工作流 ·配置和使用Visual Studio 2005调试器调试你的工作流

YAWL(Yet Another Workflow Language)

4 YAWL：Yet Another Workflow Language 定义3：是一个扩展工作流网。，。此外，辅助函数，是用来定义每个节点各自分配的预设和后置。对任何节点，均满足：和。注意：预设和后置函数和依赖于上下文，例如：扩展工作流网中的函数的使用性。如果一个节点在多个网中使用，就会不清楚这个节点的预设和后置函数是和哪个网相关的。因此，我们当有歧异产生的时候我们增加对这个网中的节点的预设和后置的注释：表示网N中节点x的预设，表示在网N中节点x的后置。定义 4. 每当我们介绍一个工作流规范，我们假设按照下面的方式定义：表示一系列的原子任务。表示一系列的符合任务。表示一系列的单实例任务。表示一系列（潜在的）多实例任务，和是所有条件的扩展集。如果表示不明确，我们将会使用下标，如：。如果在上下文中只有一个工作流规范，我们将省略下标。此外，域函数在不同的中没有重叠的部分，我们也可以省

略下标。一个工作流规范定义了一个树形结构，为了有效的使用这种结构，我们定义了函数，给出一系列的节点（如任务和条件），函数将会返回这些节点和所有的孩子节点。定义5：是一个工作流规范，定义函数：，如下，对：注意：返回在X中的每个节点和被这些节点包含的节点。对于原子任务和条件，不需要展开。对于复合任务，被这些任务包含的所有节点都包含在结果中，如递归的横穿在X中的所有复合任务。图六给出了一个工作流规范的例子来解释注意。

是一系列的原子任务，是复合任务。和。如D是唯一的含有多实例的任务（潜在的）。除了输入和输出条件，只有两个明确的条件。在集中所有的其他的条件都是含蓄的，如是一个含蓄的条件，它和连接A和B之间的弧相对应。如，如果D是展开的，那么D所包含的所有的任务和条件（包括含蓄的）都会被添加进来。 4.2 Semantics 定义2从数学的角度定义了工作流规范的语法。在这个定义的基础上，可以直接的给出一个工作流语言，如和XML相关的语言。然而在定义2中没有给出任何的语义，因此到目前为止我们只是给出了一个对工作流规范S的动态行为的直观的描述。在本节的其余部分我们将给出正式的语义。主要分3步进行，首先我们定义一些预备知识（包和标识符）。然后我们定义和工作流规范S相对应的状态空间。最后，我们给出状态转换的可能性。 Preliminaries(预备知识) 和工作流规范相对应的状态空间的定义是受有色Petri 网中的标记的概念的启发才这样定义的。状态空间包括了一些带有值的标记。既然我们从这篇文章中提取数据，因此要满足每个标记都有一个名字。我们需要依靠包来解决多个标记在同一个库所中有相同的名字的问题。此外，我们需要构造一系列的案例标识符来关联子实例和父实例，这是解决多实例问题所必须的。在这篇文章中，包被定义为字母表A中的有限多集的元素.在字母表A中上的包可以被认为是从A到自然数N的一个函数，这样就只有A中的有限数目的元素可以分配一个非0的函数值。A上的包X，且，则表示a在X中出现的次数，通常称为X中a的基数。A上的所有包集用表示。对于一个包的明确显示，一个注释类

品茗安全设施计算软件常见问题整理

品茗安全设施计算软件常见问题整理 1 安全软件中的工程说明能容纳多少字? 答:工程说明理论上应该可以存512K。(目前版本计算书中暂不支持写入计算书中,后续完善。) 2 安全计算软件安装好以后有个安全计算2013和珊瑚版,用哪个? 答:珊瑚版本是依据部分老规范的内容做的安全计算,因为新规范的发布到实施是一个漫长的过程,所以保留了珊瑚版供客户选择。目前用的基本是安全计算2013. 3 脚手架配件用量如何计算? 答:脚手架配件包括大小横杆、直角扣件、旋转扣件、脚手板等。在构选框里打勾后,“脚手架沿墙纵向长度”(一般按照建筑物外围周长计算)即显现,输入长度后即可在计算书中计算配件数量。 4 在钢管落地脚手架计算中,双立杆计算方法选择中按构造要求设计和按双立杆均匀受力有什么区别? 答:按照构造要求设置双立杆时,只将双立杆作为构造措施,副立杆不参与计算,起到加强安全性的作同时考虑两根立杆的受力,此时,副立杆参与受力计算。 5 在钢管落地脚手架计算中,地基参数中地基底面扩展面积如何设置? 答:地基底面扩展面积就是立杆下垫块的平均面积,有些客户采用的都是立杆下垫块长的钢板(槽钢)的方法,那么就可以用此块垫块的总面积除以垫块上立杆的数量即可得到。

5 风荷载没有该地区的怎么办? 答:风荷载是按照国家《建筑结构荷载规范》录入的,有些地市在荷载规范里是没有的,可以参照相邻地区的风荷载值、按照经验取值、或咨询当地气象部门当地的风速、空气密度等,点击软件中的基本风压按钮进行计算。 6 脚手架模块设计计算时,弹出以下错误报告:卸荷点水平间距必须为纵距的整数倍。答:这个是因为脚手架钢丝绳卸荷计算时,钢丝绳卸荷点水平间距的搭设位置,必须为立杆纵距的整数倍。 7 脚手架搭在楼板上的情况在施工现场上是有的,软件中可以计算么? 答:脚手架模块中,有个脚手架对楼盖影响,可以计算出脚手架立杆对于楼板的影响。 8 脚手架风荷载中,风压高度变化系数里,计算高度如何取值。答:连墙件风荷载计算高度应取脚手架顶部离地面高度计算风压高度变化系数,应为连墙件轴向力设计值与风压高度变化成正比函数关系,架体顶部最大。立杆稳定性风荷载计算高度,落地架应取离地面5M高度计算风压高度变化系数。虽此高度风荷载较小,但轴压力接近最大,综合计算最大,悬挑梁取悬挑架高度。 9 扣件抗滑系数是如何考虑的? 答:铸铁扣件在使用一段时候后,或者扣件扭紧力矩不足都会导致抗滑力会下降,采用试验实测抗滑力和国家规定的8KN比较所得的数值,或者考虑一定的安全储备,是≤1的数值。

工作流引擎(Workflow Engine )

工作流引擎（Workflow Engine ）所谓工作流引擎是指workflow作为应用系统的一部分，并为之提供对各应用系统有决定作用的根据角色、分工和条件的不同决定信息传递路由、内容等级等核心解决方案。工作流引擎（Workflow Engine ）什么是工作流引擎（Workflow Engine ）例如开发一个系统最关键的部分不是系统的界面，也不是和数据库之间的信息交换，而是如何根据业务逻辑开发出符合实际需要的程序逻辑并确保其稳定性、易维护性（模块化和结构化）和弹性（容易根据实际业务逻辑的变化作出程序上的变动，例如决策权的改变、组织结构的变动和由于业务方向的变化产生的全新业务逻辑等等）。 Workflow 引擎解决的就是这个问题：如果应用程序缺乏强大的逻辑层，势必变得容易出错（信息的路由错误、死循环等等）。就好比一辆汽车，外表做得再漂亮，如果发动机有问题就只是一个摆设。应用系统的弹性就好比引擎转速方面的性能，加速到100 公里需要1 个小时（业务流程发生变动需要进行半年的程序修改）还能叫好车吗？引擎动不动就熄火（程序因为逻辑的问题陷入死循环）的车还敢开吗？工作流解决方案与传统管理软件的关系传统的管理软件注重解决企业应用层现存的问题（例如提高企业的资源配置率或提高单一员工的生产效率）。例如：EXCEL 可以提高员工画表格的效率、财务软件可以规范财务人员的工作并提高账目查询的效率、CRM 可以规范客户管理从而使客户资源掌握在公司手中而不是被一部分业务人员把持并提高客户响应时间、ERP 解决的是如何配置企业资源：使企业的人力资源、财力资源和物资资源能够根据业务的需求实现最大化配置。workflow 关注的是如何缩短流程闲置时间，从而提高企业的业务处理能力并使企业能够关注于真正对企业有意义的增值业务上。从建立企业神经系统的角度也许更能理解两者的区别。传统软件不能解决工作流的问题，例如ERP 关注的是企业的资源配置，但不可能解决资源传输过程中的损耗和降低传输（流程）的成本；同样workflow也不能完全解决传统管理软件所能解决的问题，例如对生产管理的MRP 系统所能解决的生产过程控制通过workflow很难实现。但一个好的传统软件如果希望能自动化地在整个企业

品茗安全计算软件操作文件

问题：1、软件打开时,跳出对话框failed to set data for. 这种情况可能是软件没装好.部分文件缺失，建议重新安装一遍试试看. 2、在软件中无法操作，对梁不设置对拉螺栓对拉螺栓是可以设置地.在梁侧模板计算中设置.如果不设置对拉螺栓，需要在支陣设豐第i道玄撐距聲底昵离（mm）支擇死式 10固定变偉 2320固定吏撑表中,将“距梁底距离”中地两个数据输入为“0”和“梁高- 板厚”. 3、梁底支撑小横杆根数及间距无法设置当梁底有附加立杆时，该参数受软件控制，无法设置. 4、梁底增加支撑地间距无法设置不是很明确，梁底增加支撑如果是指附加地立杆，可以在表中选择自定义地方式. 按混凝土粱璽宽均分? 粱底闻加立拄邪養方式：梁触枷亚柱俄次距梁左侧立柱距离伽）；麋融椁小袈根数：如果指地是梁底地支撑小梁根数（间距），小梁地间距是根据根数和梁宽进行均分计算地 5、荷载参数里施工人员设备荷载和振捣荷载只需要计算一个就行了.（参考规JGJ162-2008 ）答：梁受力支撑计算施工人员设备荷载，板受力支撑计算振捣

荷载,如果梁和板都受力两个都需要计算. 6、悬挑脚手架计算中, “拉绳与支撑杆”设置中“共点”与“平行”有什么区别？答：平行和共点,对于单道拉绳或支撑来说,没什么大地区别, 它们地区别是在于, “平行”时输入地是拉（绳支撑）与水平面地夹角. 共点时输入地是这个夹角所造成地两个直角边地长度,软件通过这两个直角边长来计算夹角.如果是多道支撑或拉结,就比较明显了.平行是多道支撑或拉结近似平行线.共点是支撑或拉结近似节点集中一点. 7、工地承重架和脚手架地扣件,检测中,直角扣件、旋转扣件,抗破坏和抗滑不合格,请问在品茗安全计算中,怎么进行复算啊？答：对于扣件抗滑力检测不合格地情况,在相关部门许可地情况下,可以降低承载力使用.或者增加双扣件进行支撑.或者直接清除不合格材料,改用检测合格地材料进行支撑. 如果是属于扣件抗破坏性能检验不合格,则需要更换扣件材料.或者降低允许承载力,加密支撑杆件等方式进行使用. 以上措施仅限于材料不合格在允许围或者相关部门允许地情况下使用,如果不允许使用,建议更换检测合格地材料使用, 毕竟这也是关系到人民生命财产安全地大事. 安全计算软件常见问题整理

PKPM建筑施工安全设施计算软件(2018版)

1.建筑施工安全设施计算软件计算依据：《建筑施工脚手架安全技术统一标准》GB51210-2016 《建筑施工碗扣式钢管脚手架安全技术规范》JGJ166-2016 《建筑施工临时支撑结构技术规范》 JGJ 300-2013 《建筑施工扣件式钢管脚手架安全技术规程》 JGJ 130-2011 《混凝土结构工程施工规范》 GB 50666-2011 《建筑工具式脚手架安全技术规范》 JGJ 202-2010 《建筑施工门式钢管脚手架安全技术规范》 JGJ 128-2010 《建筑施工模板安全技术规范》 JGJ 162-2008 《建筑施工承插型盘扣脚手架规程》 JGJ231-2010 《建筑结构荷载规范》 GB50009-2012 《塔式起重机混凝土基础工程技术规程》 JGJ/T187-2009 《混凝土结构设计规范》 GB50010-2010 《建筑工程冬期施工规程》 JGJ/T 104-2011 …… 提供大量的计算参数用表，供用户参考，计算方便准确，计算书详细；同时提供了各种脚手架工程、模板工程、施工电梯工程、碗扣脚手架工程、盘扣脚手架工程、工具式脚手架工程、塔吊工程、结构吊装、降排水、临时工程等的计算和强大的方案绘图功能，可以将计算书和绘制的详图直接插入到方案中，形成完整的WORD格式施工专项方案。主要内容有：各种类型脚手架计算；模板计算；塔吊基础计算；结构吊装工程计算；大体积混凝土工程计算；混凝土工程计算；临时设施工程计算及钢筋工程计算等涵盖施工安全计算的几十种计算模型。总计算工具箱脚手架计算模型

模板计算模型塔吊基础计算模型混凝土工程计算模型市政工程计算模型

品茗安全计算软件新手入门教程1梁模板扣件式

1、《建筑施工模板安全技术规范》JGJ162-2008 2、《建筑施工扣件式钢管脚手架安全技术规范》JGJ130-2011 3、《建筑结构荷载规范》GB50009-2012 4、《钢结构设计规范》GB50017-2003 5、《混凝土结构设计规范》GB 50010-2010 6、《混凝土结构工程施工规范》GB50666-2011 7、《建筑施工临时支撑结构技术规范》JGJ300-2013 8、建筑施工计算手册(第二版) 基本知识梁模板设置附加立杆1 梁模板设置附加立杆2 梁模板设置附加主梁参数解析 ①基本参数模板规范计算依据：JGJ130-2011,JGJ162-2008,GB50666-2011,JGJ300-2013共四本计算规范，不同计算规范荷载取值、构造要求等都不相同，计算结果也会有差异。如何选择计

算依据：根据工程所在地专家比较认可（常规使用）规范来计算，非专家论证方案选择规范要和监理工程师确定。 ②混凝土工程属性新浇混凝土板名称：验算模板支架所在混凝凝土板名称，根据实际工况填写。新浇混凝土板板厚（mm）：验算模板支架所在混凝凝土板厚度。模板支架纵向长度L(m):指和所验算混凝土楼板模板支架架体连接一体架体，整体纵向长度（整体相对较长的一边为纵向）模板支架横向长度B(m): 指和所验算混凝土楼板模板支架架体连接一体架体，整体横向长度（整体相对较短的一边为纵向）。模板支架纵、横向长度示意图 ③支架体系设计混凝土浇筑施工方式：共分为六种方式，根据实际工况进行选择。混凝土浇筑施工方式每纵距内附加梁底支撑主梁根数：附加梁底支撑主梁指相邻立柱之间，增加的主梁。附加主梁1根荷载传递至立柱方式：根据现场实际工况进行选择。包括可调托、单双扣件三种类型。

恒智天成安全计算软件板模板(门架支撑)计算书【精选】

恒智天成安全计算软件板模板(门架支撑)计算书本计算书依据《建筑施工模板安全技术规范》（JGJ162-2008）、《建筑施工门式钢管脚手架安全技术规范》（JGJ128-2000）、《建筑施工计算手册》江正荣著、《建筑结构荷载规范》(GB 50009-2001)、《混凝土结构设计规范》（GB50010-2002）、《钢结构设计规范》(GB 50017-2003)等规范编制。板段：B1。模板支撑体系剖面图

(一) 板模板荷载参数新浇筑砼自重标准值G 2k ：24kN/m3；钢筋自重标准值G 3k ：1.1kN/m3；板底模板自重标准值G 1k ：0.3kN/m2；承受集中荷载的模板单块宽度：1830mm；施工人员及设备荷载标准值Q 1k ：计算模板和直接支承模板的小梁时取2.5kN/m2；计算直接支承小梁的主梁时取1.5kN/m2；计算支架立柱等支承结构构件时取1kN/m2； (二) 门架静荷载参数水平架5步4设；脚手板5步1设；水平加固杆采用Φ42 × 2.5mm钢管，4步1设；剪刀撑采用Φ42 × 2.5mm钢管，按照4步4跨设置； 1跨1步架内包含旋转扣件4个，直角扣件1个；附件、安全网重量(kN/m)：0.02 栏杆重量 (kN/m)：0.01 3.板底模板参数搭设形式为：2层梁上顺下横单门架； (一) 面板参数面板采用克隆(平行方向)12mm厚覆面木胶合板；厚度：12mm；抗弯设计值fm：31N/mm2；弹性模量E：11500N/mm2； (二) 第一层支撑梁参数材料：1根100×100矩形木楞；间距：500mm；木材品种：太平洋海岸黄柏；弹性模量E：10000N/mm2；抗压强度设计值fc：13N/mm2；抗弯强度设计值fm：15N/mm2；抗剪强度设计值fv：1.6N/mm2； (三) 第二层支撑梁参数

lotus workflow工作流控制方案

工作流控制方案 1流程方案流程控制整体思路为利用Wordflow自身机制对文档进行路由，路由完毕后对活动的可能所有者、活动的读者按照定制域设定及所选人员进行修正。各类路由机制详细说明如下： 1.1 一般路由从活动A路由到活动B，不关心活动B是否已完成，取新选择的人员作为活动可能所有者，这是流程中最常用的路由类型，路由图示说明如下：活动A可以多人也可以单人，活动A为多人处理时，若非决策路由（设置DispChoice定制域），多人操作相同，都不选择人员，活动B的活动所有者根据公式自动计算，如发文会签完毕到拟稿人确定的路由、甘肃督办拟稿人确定到会签的路由等；若有多个决策路由，可能仅第一个处理的人选择决策完成路由，其他人不再处理（甘肃机制、西北网未设置MultiChoice时机制），目前无此实例；也可能多人操作相同，都不选择人员，活动B的活动所有者根据公式自动计算（西北网设置MultiChoice时机制，同时需设置NoSelChoice），如西北网部主任批示到处长批办的路由；活动A为单人处理时，可以由公式自动计算也可以手动选择人员，如起草到部主任审核的路由、秘书核稿到领导签发的路由、西北网部主任批示到处长批办的路由等。若活动B的活动所有者为自动计算，计算结果为空时则会引起路由出错。此路由之后对流程的各种特殊操作情况有： 1)、收回。活动A最后一个处理人可以收回，收回后工作路由到活动A，活动所有者为活动A的最后一个处理人，收回后不能再返上一人。

2)、返回上一人。活动B的第一个处理人返回上一人，工作路由到活动A，活动所有者为活动A的最后一个处理人。返回上一人后活动B的第一个处理人可以再收回，收回后工作路由到活动B，活动所有者为活动B的第一个处理人；活动A的最后一个处理人也可以返回上一人，返回后工作路由到活动B，活动所有者为活动B的第一个处理人，以后可以在A、B活动间循环。 3)、特送。活动B的任一处理人可以进行特送到另一活动C，特送按照流程配置选择活动C的活动所有者，特送后特送人可以收回，收回后工作路由到活动B，活动所有者为特送人；活动C的第一个处理人可以返上一人，返回后工作路由到活动B，活动所有者为特送人，若特送人在返回上一人，则会在特送人和活动C的第一个处理人间循环；活动C的部分人处理后，特送人可以上一节点收回，收回后工作路由到活动B，活动所有者为特送人。 4)、上一节点收回。活动B的部分人处理后，活动A最后一个处理人可以上一节点收回，上一节点收回后工作路由到活动A，活动所有者为活动A的最后一个处理人。 5)、管理特送。应用管理员可以管理特送到活动C，特送时可在组织机构中选择任一人员作为活动C的活动所有者，管理特送同时更新了流程版本（西北网），但必须保证管理特送时按照正常流程到活动C也可以正常流转才可特送成功，管理特送后不能再收回、返回上一人、上一节点收回。 1.2 返回路由从活动B路由到活动A，活动A在之前已经完成并记录了处理人（通过设置destitem定制域），取活动A的最后一个处理人（西北网机制）或活动A的全部处理人（甘肃机制），路由图示说明如下：

软件部分工程定额计算实例

软件部分工程定额定额标准依据<中国软件行业-软件工程定额标准>. 相关名词解释：功能点估算是一种基于软件功能计数来评估软件规模的估算方法，其中也考虑到了性能/安全/质量等因素带来的规模调整，但不考虑软件开发商的企业背景/ 经验/所用技术等非产品因素。功能点估算的优点是：用户单位和软件开发商都可以理解；在项目早期利用有限的功能描述即可进行估算。 c）国际功能点用户组（IFPUG，International Function Point Users Group）IFPUG 为功能点的识别和计数提供了国际标准，使不同的人对同一软件的规模的认识是相同的。本标准提供的简易识别规则参考了 IFPUG 标准规则的功能点计数方法。 d） NESMA（Netherlands Software Metrics Association） NESMA 是荷兰的功能点组织，也是世界第二大功能点组织。其创造的一系列简化功能点方法在估算界占有重要地位。 e）国际软件基准比对标准组（ISBSG，International Software Benchmarking Standard Group） ISBSG 长期从事基于功能点的跨企业跨行业的项目数据比对，拥有大量的基于功能点的历史数据。本标准中所采用的一些数值参考了 ISBSG 公布的数据。ISBSG 在中国的分支机构是 CSBSG。功能点计数元素

功能点计数元素包括以下 5 个： a）内部逻辑文件（Internal Logical File，ILF，以下简称内部数据）软件内部需要维护（如增删改查）的数据。 b）外部接口文件（External Interface File，EIF，以下简称外部接口）在其它系统中维护但本软件需要调用的数据。 c）外部输入（External Input，EI）向软件输入数据或发送指令。 d）外部输出（External Output，EO）软件向使用者或其它系统输出的数据或发送的指令。 e）外部查询（External Query，EQ） EQ 指使用软件进行的简单查询。其中 ILF、EIF 是功能点计数时的数据元素，EI、EO、EQ 是功能点计数时的业务元素。每种计数元素都对应一定的功能点分值。累计得到整个软件的计数规模。由于利用已经识别出来的功能点计数元素计算规模，因此这种方法非常客观。在 IFPUG 的功能点计数手册中，ILF、EIF、EI、EO、EQ 都有严格复杂的识别标准，比较难以掌握。本标准的估算方法和估算工具表提供了简易识别标准，供使用者快速估算而又不产生显着的偏差。