Object Management Group
Framingham Corporate Center
492 Old Connecticut Path
Framingham, MA 01701-4568
Telephone: +1-508-820 4300
Facsimile: +1-508-820 4303
Workflow Management Facility
Request For Proposal
OMG Document: cf/97-05-06
Submissions due: August 29th, 1997
Objective of this RFP
The Workflow Management Facility defines interfaces and their semantics required to manipulate and execute interoperable workflow objects and their meta-data. The Workflow Management Facility will serve as a high-level integrating platform for building flexible workflow management applications incorporating objects and existing applications
This RFP solicits Submissions for the following:
?Workflow Management Facility
For further details see Chapter 6 of this document.
1. Introduction
1.1.1 Goals of OMG
The Object Management Group (OMG) is the world’s largest software consortium with a membership of over 600 vendors, developers, and end users. Established
in 1989, its mission is to promote the theory and practice of Object Technology
(OT) for the development of distributed computing systems.
A key goal of OMG is create a standardized object-oriented architectural
framework for distributed applications based on specifications that enable and
support distributed objects. Objectives include the reusability, portability, and
interoperability of object-oriented software components in heterogeneous
environments. To this end, the OMG adopts interface and protocol specifications,
based on commercially available object technology, that together define an Object Management Architecture (OMA).
1.2 Organization of this document
The remainder of this document is organized as follows:
Chapter 2 - Architectural Context - background information on OMG’s Object
Management Architecture.
Chapter 3 - Adoption Process - background information on the OMG specification adoption process.
Chapter 4 - Instructions for Submitters - explanation of how to make a
submission to this RFP.
Chapter 5 - General Requirements on Proposals - requirements and evaluation
criteria that apply to all proposals submitted to OMG.
Chapter 6 - Specific Requirements on Proposals - problem statement, scope of
proposals sought, mandatory and optional requirements, issues to be discussed,
evaluation criteria, and timetable that apply specifically to this RFP.
Additional RFP-specific chapters may also be included following Chapter 6.
1.3 References
The following documents are referenced in this document:
Richard Soley (ed.), Object Management Architecture Guide, Third Edition ,
Wiley, June 1995.
The Common Object Request Broker: Architecture and Specification, Revision
2.0, July 1995.
CORBAservices: Common Object Services Specification, Revised Edition,
March 1995.
CORBAfacilities Architecture, Revision 4.0, November 1995.
Business Committee RFP Attachment, OMG Document omg/96-01-01.
Policies and Procedures of the OMG Technical Process, OMG Document
pp/96-12-01 or successor.
These documents can be obtained by contacting OMG at document@https://www.doczj.com/doc/2913564539.html,.
Many OMG documents, including this document, are available electronically from OMG’s document server. Send a message containing the single line “help” to
server@https://www.doczj.com/doc/2913564539.html, for more information.
For more information about OMG visit OMG’s Web page (URL http://
https://www.doczj.com/doc/2913564539.html,/). If you have general questions about this RFP send email to
responses@https://www.doczj.com/doc/2913564539.html,.
2. Architectural
Context
2.1 Object Management Architecture
The Object Management Architecture Guide (OMAG) describes OMG’s technical
objectives and terminology and provides the conceptual infrastructure upon which supporting specifications are based. The guide includes the OMG Object Model,
which defines common semantics for specifying the externally visible
characteristics of objects in a standard implementation-independent way, and the
OMA Reference Model.
The Reference Model identifies and characterizes the components, interfaces and protocols that compose the OMA. This includes the Object Request Broker (ORB) component that enables clients and objects to communicate in a distributed
environent, and four categories of object interfaces:
? Object Services are interfaces for general services that are likely to be used in any program based on distributed objects.
? Common Facilities are interfaces for horizontal end-user-oriented facilities applicable to most application domains.
? Domain Interfaces are application domain-specific interfaces.
? Application Interfaces are non-standardized application-specific interfaces.
A second part of the Reference Model introduces the notion of domain-specific
Object Frameworks. An Object Framework component is a collection of
cooperating objects that provide an integrated solution within an application or
technology domain and which is intended for customization by the developer or
user.
Through a series of RFPs, OMG is populating the OMA with detailed
specifications for each component and interface category in the Refe rence Model.
Adopted specifications include the Common Object Request Broker Architecture
(CORBA), CORBAservices, and CORBAfacilities.
The wide-scale industry adoption of OMG's OMA provides application developers
and users with the means to build interoperable software systems distributed
across all major hardware, operating system, and programming language
environments.
2.2 CORBA
The Common Object Request Broker Architecture defines the programming
interfaces to the OMA ORB component. An ORB is the basic mechanism by which objects transparently make requests to - and receive responses from - each other on the same machine or across a network. A client need not be aware of the
mechanisms used to communicate with or activate an object, how the object is
implemented, nor where the object is located. The ORB thus forms the foundation for building applications constructed from distributed objects and for
interoperability between applications in both homogeneous and heterog eneous
environments.
The OMG Interface Definition Language(IDL) provides a standardized way to
define the interfaces to CORBA objects. The IDL definition is the contract between the implementor of an object and the client. IDL is a strongly typed declarative
language that is programming language-independent. Language mappings enable objects to be implemented and sent requests in the developer’s programming
language of choice in a style that is natural to that language.
CORBA 2.0 is an extension and restructuring of the earlier CORBA 1.2
specification. CORBA 2.0 is a family of specifications consisting of the following
components:
? Core (including IDL syntax and semantics)
? IDL C language mapping
? IDL C++ language mapping
? IDL SmallTalk language mapping (added in 1995)
? IDL Ada’95 language mapping (added in 1996)
? Interoperability
Each component is a separate compliance point. The minimum required for a
CORBA-compliant implementation is adherence to the core and one language
mapping.
2.3 CORBA/Interoperability
Interoperability between CORBA-compliant ORBs is provided by OMG’s Internet
Inter-ORB Protocol (IIOP). Adopted in December 1994 as the mandatory CORBA
2.0 protocol for “out of the box” interoperability, IIOP is the TCP/IP transport
mapping of a General Inter-ORB Protocol(GIOP). IIOP enables requests to be
sent to networked objects managed by other ORBs in other domains.
The OMG interoperability architecture also accommodates communication using
optional Environment-Specific IOPs (ESIOPs), the first of which is the DCE-
CIOP.
2.4 CORBAservices
Object Services are general purpose services that are either fundamental for
developing useful CORBA-based applications composed of distributed objects, or that provide a universal - application domain-independent - basis for application
interoperability.
Object Services are the basic building blocks for distributed object applications.
Compliant objects can be combined in many different ways and put to many
different uses in applications. They can be used to construct higher level facilities
and object frameworks that can interoperate across multiple platform
environments.
Adopted OMG Object Services are collectively called CORBAservices and include Naming, Events, LifeCycle, Persistent Object, Relationships, Externalization,
Transactions, Concurrency Control, Licensing, Query, Properties, Security, Time,
Collections, and Trading Services.
2.5 CORBAfacilities
Common Facilities are interfaces for horizontal end-user-oriented facilities
applicable to most domains. Adopted OMG Common Facilities are collectively
called CORBAfacilities and include an OpenDoc-based Distributed Document
Component Facility.
A specification of a Common Facility or Object Service typically includes the set of
interface definitions - expressed in OMG IDL - that objects in various roles must
support in order to provide, use, or participate in the facility or service. As with all specifications adopted by OMG, facilities and services are defined in terms of
interfaces and their semantics, and not a particular implementation.
2.6 Object Frameworks and Domain Interfaces
Unlike the interfaces to individual parts of the OMA “plumbing” infrastructure,
Object Frameworks are complete higher level components that provide
functionality of direct interest to end-users in particular application or technology
domains. They are vertical slices down the OMG “interface stack”.
Object Frameworks are collections of cooperating objects categorized into
Application, Domain, Facility, and Service Objects. Each object in a framework
supports (through interface inheritance) or makes use of (via client requests)
some combination of Application, Domain, CORBAfacilities, and CORBAservices
interfaces.
A specification of an Object Framework defines such things as the structure,
interfaces, types, operation sequencing, and qualities of ser vice of the objects that make up the framework. This includes requirements on implementations in order
to guarantee application portability and interoperability across different platforms.
Domain Task Force RFPs are likely to focus on Object Framework specifications
that include new Domain Interfaces for application domains such as Finance,
Healthcare, Manufacturing, Telecom, Electronic Commerce, and Transportation.
3. Adoption
Process
3.1 Introduction
OMG adopts specifications for interfaces and protocols by explicit vote on a
technology-by-technology basis. The specifications selected each fill in a portion
of the OMA Reference Model. OMG bases its decisions on both business and
technical considerations. Once a specification is adopted by OMG, it is made
available for use by both OMG members and non-members.
For more detailed information on the adoption process see the Policies and
Procedures of the OMG Technical Process.
3.2 R?le of Board of Directors
The OMG Board of Directors votes to formally adopt specifications on behalf of
OMG. The OMG Technology Committees (Domain and Platform TCs) and
Architecture Board (AB) provide technical guidance to the Board of Directors. In
addition, the Business Committee of the Board provides guidance to ensure that
implementations of adopted specifications are made commercially available.
3.3 R?le of Technology Committees and Architecture Board
Submissions to RFPs are evaluated by the TC Task Force (TF) that initiated the
RFP. Selected specifications are recommended to the parent TC after being
reviewed by the Architecture Board for consistency with the OMA. The full TC
then votes to recommend adoption to the OMG Board.
3.4 R?le of Task Forces
The role of the initiating TF is to technically evaluate submissions and select one
or more specifications that satisfy the requirements of the RFP. The process
typically takes the following form:
? Voter Registration
Interested TF members may register to participate in specification selection
votes for an RFP. Registration ends on a specified date 6 or more weeks after
the announcement of the registration period. The registration closure date is
typically around the time of initial submissions. Companies who have submitted
an LOI are automatically registered to vote.
? Initial Submissions
Initial submissions are due by a specified deadline. Submitters normally present
their proposals at the next following meeting of the TF. Initial submissions are
expected to be full and complete proposals and working implementations of the
proposed specifications are expected to exist at the time of submission.
? Evaluation Phase
A period of approximately 120 days follows during which the TF evaluates the
submissions. During this time submitting companies have the opportunity to
revise and/or merge their initial submissions, if they so choose.
? Revised Submissions
Final revised submissions are due by a specified deadline. Submitters again
normally present their proposals at the next following meeting of the TF.
Finalists may be requested to demonstrate implementations of their proposal.
? Selection Vote
When the registered voters of the TF believe that they sufficiently u nderstand
the relative merits of the revised submissions, a specification selection vote is
taken.
3.5 Goals of the evaluation
The primary goals of the TF evaluation process are to:
? Provide a fair and open process
? Force a critical review of the submissions and discussion by all members of the TF
? Give feedback to allow submitters to address concerns in their revised submissions
? Build consensus on acceptable solutions
? Enable voting members to make an informed selection decision
Submitters are expected actively to contribute to the evaluation process.
4. Instructions for Submitters
Effort
4.1 Submission
Unlike a submission to an OMG Request For Information (RFI), an RFP
submission may require significant effort in terms of document preparation,
presentations to the initiating TF, and participation in the TF evalu ation process.
Several staff months of effort might be necessary. OMG is unable to reimburse
submitters for any costs in conjunction with their submissions to this RFP.
4.2 Letter of Intent
A Letter of Intent (LOI) must be submitted to the OMG Business Co mmittee
signed by an officer of your organization signifying your intent to respond to the
RFP and confirming your organization’s willingness to comply with OMG’s terms
and conditions, and commercial availability requirements. These terms,
conditions, and requirements are defined in the Business Committee RFP
Attachment and are reproduced verbatim in section 4.3 below.
The LOI should designate a single contact point within your organization for
receipt of all subsequent information regarding this RFP and your submission. The name of this contact will be made available to all OMG members. The LOI is
typically due 60 days before the deadline for initial submissions. LOIs must be
sent by fax or paper mail to the “RFP submissions Desk” at the main OMG
address shown on the first page of this RFP.
Here is a suggested template for the Letter of Intent:
This letter confirms the intent of <___organisation required___> (the organisation) to submit a response to the OMG <___RFP name required___> RFP. We will
grant OMG and its members the right to copy our response for review purposes
as specified in section 4.6 of the RFP. Should our response be adopted by OMG
we will comply with the OMG Business Committee terms set out in section 4.3 of
the RFP and in document omg/97-01-01.
<____contact name and details required____> will be responsible for liai-son with OMG regarding this RFP response.
The signatory below is an officer of the organisation and has the approval and
authority to make this commitment on behalf of the organisation.
<___signature required____>
4.3 Business Committee RFP Attachment
Terms and Conditions
The OMG Business Committee has produced a document entitled “OMG Policy
on Adoption of Specifications”. When reviewing submissions to each RFP, the
specific items that the OMG Business Committee will be considering during the
selection process are outlined below:
? The optimization of interoperability and portability goals across multiple platforms.
? Commitment by the proposed technology supplier to make the implementation available on commercially reasonable terms, applied in a non discriminatory
fashion.
? Submission of a Standard License Agreement and Support plans
? A preferred, but not required, method for achieving multi-platform
interoperability is source code licensing. Please include any provisions as such.
? Assurance that the results in the duplication of the “look and feel” of any aspects of such proponents implementations from specifications will not result
in infringement or obligation to pay royalties.
? Plans for future revisions, enhancements, maintenance.
? Agreement to grant to the Object Management Group, Inc., a non-exclusive, royalty-free, paid-up, worldwide license to copy and distribute the specification
document and to modify the document and distribute copies of the modified
version. Implementations or instantiations of the specifications are owned by
the developer.
? Upon OMG's acceptance of the sponsoring company's interfaces, the sponsoring company agrees to provide all documentation in an OMG
prescribed format and in OMG endorsed terminology.
Definition of Commercial Availability
For technology to be accepted and adopted by the OMG Board Of D irectors
(reference OMG document tilted “OMG Policy on Adoption of Specifications -
2/12/90”) it must be commercially available within twelve (12) months or less from when the OMG Task Force (prior to the technical Committee and Board vote)
adopted the specification(s). This is required for proof of concept and expedient
implementation of actual product and licensing procedures. Commercial
availability is delineated as:
? Technology that has been publicly announced as a product or e mbodied within another product.
? Technology that is of production/manufacturing quality, has cleared a process of product shipment authorization, and can be demonstrated at OMG request
(including installation, documentation, service, and support). Demonstrations
may be required following RFP presentations to the OMG Technical
Committee.
? Technology that can be referenced by at least two (2) consumers (customers) of the technology.
A statement of commercial availability must be accompanied by a letter of
authorization by an officer of the company proposing the technology.
4.4 Responding to RFP items
Separate proposals
Unless otherwise indicated in Chapter 6, independent proposals are s olicited for
each separate item in the RFP. Each item is considered a separate architectural
entity for which a proposal may be made. A submitter may respond to any or all
items. Each item will be evaluated independently by the initiating TF. Submissions that do not present clearly separable proposals for multiple items may therefore
be at a disadvantage.
It should be noted that a given technology (e.g. software product) may support
two or more RFP items. So long as the interfaces for each item are separable, this is not precluded.
Complete proposals
Proposals for each separate RFP item must be complete. A submission must
propose full specifications for each item and address all the relevant general and
specific requirements detailed in this RFP.
Additional specifications
Submissions may include additional specifications for items not covered by the
RFP which they believe to be necessary and integral to their proposal. Information on these additional items should be clearly distinguished.
Submitters must give a detailed rationale as to why these specifications should
also be considered for adoption. However submitters should note that a TF is
unlikely to consider additional items that are already on the roadmap of an OMG
TF, since this would preempt the normal adoption process.
Alternative approaches
Submitters may provide alternative RFP item definitions, categorizations, and
groupings so long as the rationale for doing so is clearly stated. Equally,
submitters may provide alternative models for how items are provided within the
OMA if there are compelling technological reasons for a different approach.
4.5 Confidential and Proprietary Information
The OMG specification adoption process is an open process. Responses to this
RFP become public documents of the OMG and are available to members and
non-members alike for perusal. No confidentiality or proprietary information of any kind will be accepted in a submission to this RFP.
Waiver
4.6 Copyright
If a submitted document is copyrighted, a waiver of copyright for unlimited
duplication by the OMG is required to be stated in the document. In addition, a
limited waiver of copyright is required that allows each OMG member to make up
to fifty (50) copies of the document for review purposes only.
4.7 Proof of Concept
Submissions must include a “proof of concept” statement, explaining how the
submitted specifications have been demonstrated to be techn ically viable. The
technical viability has to do with the state of development and maturity of the
technology on which a submission is based. This is not the same as commercial
availability. Proof of concept statements can contain any information deemed
relevant by the submitter, for example:
“This specification has completed the design phase and is the process of being
prototyped.”
“An implementation of this specification has been in beta-test for 4 months.”
“A named product (with a specified customer base) is a realization of this
specification.”
It is incumbent upon submitters to demonstrate to the satisfaction of the TF the
technical viability of their proposal. OMG will favor proposals based on technology for which sufficient relevant experience has been gained in CORBA-based or
comparable environments.
4.8 Format of RFP Submissions
This section provides guidance on how to structure your RFP submission.
General
? Submissions that are concise and easy to read will inevitably receive more consideration.
? Submitted documentation should be confined to that directly relevant to the items requested in the RFP. If this is not practical, submitters must make clear
what portion of the documentation pertains directly to the RFP and what portion
does not.
The models and terminology in the Object Management Architecture Guide and CORBA should be used in your submission. Where you believe this is not
appropriate, describe and provide a rationale for the models and terminology you believe OMG should use.
Suggested Outline
A three part structure for submissions is suggested:
PART I
? Copyright Waiver (see 4.5)
? Submission contact point (see 4.2)
? Overview or guide to the material in the submission
? Overall design rationale (if appropriate)
? Statement of proof of concept (see 4.6)
? Resolution of RFP mandatory and optional requirements
Explain how your proposal satisfies the mandatory and (if applicable) optional
requirements stated in Chapter 6. References to supporting material in Part II
should be given.
In addition, if your proposal does not satisfy any of the general r equirements
stated in Chapter 5, provide a detailed rationale.
? Responses to RFP issues to be discussed
Discuss each of the “Issues To Be Discussed” identified in Chapter 6.
PART II
? Proposed specification
PART III
? Summary of optional versus mandatory interfaces
Submissions must clearly distinguish interfaces that all implementa-tions must
support from those that may be optionally supported.
? Proposed compliance points
Submissions should propose appropriate compliance points for
implementations.
? Changes or extensions required to adopted OMG specifications
Submissions must include a full specification of any changes or extensions
required to existing OMG specifications. This should be in a form that enables
“mechanical” section-by-section revision of the existing specification.
? Complete IDL definitions
For reference purposes and to facilitate electronic usage, submissions should
reproduce in one place a complete listing in compilable form of the IDL
definitions proposed for standardization.
4.9 How to Submit
Submitters should send an electronic version of their submission to the RFP
Submissions Desk (rfp@https://www.doczj.com/doc/2913564539.html,) at OMG by 5:00 PM U.S. Eastern Standard
Time (22:00 GMT) on the day of the submission deadline. Acceptable formats are Postscript, ASCII, FrameMaker, Word, and Word-Perfect. Submitters should make
sure they receive electronic or voice confirmation of the successful receipt of their submission.
Submitters should also send, within three (3) working days after the submission deadline, a single hardcopy version of their submission to the attention of the “RFP Submissions Desk” at the main OMG address shown on the first page of this RFP.
In addition, submitters are responsible for making available 100 paper copies to attendees of the TF meeting immediately following a submission deadline. There are normally two such presentation meetings, one for the initial and one for the revised submissions.
5. General Requirements on Proposals
Requirements
5.1 Mandatory
5.1.1 Proposals shall express interfaces in OMG IDL. Proposals should follow accepted
OMG IDL and CORBA programming style. The correctness of the IDL shall be
verified using at least one IDL compiler (and preferably more then one). In
addition to IDL quoted in the text of the submission, all the IDL associated with the proposal shall be supplied to OMG in compiler-readable form.
5.1.2 Proposals shall specify operation behavior, sequencing, and side-effects (if any).
5.1.3 Proposals shall be precise and functionally complete. There should be no implied
or hidden interfaces, operations, or functions required to enable an
implementation of the proposed specification.
5.1.4 Proposals shall clearly distinguish mandatory interfaces and other specification
elements that all implementations must support from those that may be optionally supported.
5.1.5 Proposals shall reuse existing OMG specifications including CORBA,
CORBAservices, and CORBAfacilities in preference to defining new interfaces to
perform similar functions.
5.1.6 Proposals shall justify and fully specify any changes or extensions required to
existing OMG specifications. This includes changes and extensions to CORBA
inter-ORB protocols necessary to support interoperability. In general, OMG favors upwards compatible proposals that minimize changes and extensions to existing
OMG specifications.
5.1.7 Proposals shall factor out functions that could be used in different co ntexts and
specify their interfaces separately. Such minimality fosters re-use and avoids
functional duplication.
5.1.8 Proposals shall use or depend on other interface specifications only where it is
actually necessary. While re-use of existing interfaces to avoid duplication will be
encouraged, proposals should avoid gratuitous use.
5.1.9 Proposals shall specify interfaces that are compatible and can be used with
existing OMG specifications. Separate functions doing separate jobs should be
capable of being used together where it makes sense for them to do so.
5.1.10 Proposals shall preserve maximum implementation flexibility. Implementation
descriptions should not be included, however proposals may specify constraints
on object behavior that implementations need to take into account over and above those defined by the interface semantics.
5.1.11 Proposals shall allow independent implementations that are substitutable and
interoperable. An implementation should be replaceable by an alternative
implementation without requiring changes to any client
5.1.12 Proposals shall be compatible with the architecture for system distribution defined
in ISO/IEC 10746, Reference Model of Open Distributed Processing (ODP).
Where such compatibility is not achieved, the response to the RFP must include
reasons why compatibility is not appropriate and an outline of any plans to
achieve such compatibility in the future.
5.1.13 In order to demonstrate that the service or facility proposed in response to this
RFP, can be made secure in environments requiring security, answers to the
following questions shall be provided:
1) What, if any, are the security sensitive objects that are introduced by the
proposal?
2) Which accesses to security-sensitive objects must be subject to security
policy control?
3) Does the proposed service or facility need to be security aware?
4) What CORBAsecurity level and options are required to protect an
implementation of the proposal? In answer to this question, a re asonably
complete description of how the facilities provided by the level and options
(e.g. authentication, audit, authorization, message protection etc.) are used to
protect access to the sensitive objects introduced by the proposal shall be
provided.
5) What default policies should be applied to the security sensitive o bjects
introduced by the proposal?
6) What security considerations must the implementers of your proposal be
aware of?
criteria
5.2 Evaluation
Although the OMG adopts interface specifications, the technical viability of
implementations will be taken into account during the evaluation pro cess. The
following criteria will be used:
5.2.1 Performance
Potential implementation trade-offs for performance will be considered.
5.2.2 Portability
The ease of implementation on a variety of ORB systems and software platforms will be considered.
5.2.3 Securability
The answers to questions in section 5.1.13 shall be taken into consi deration to
ascertain that an implementation of the proposal is securable in an environment
requiring security.
5.2.4 Compliance: Inspectability and Testability
The adequacy of proposed specifications for the purposes of compliance
inspection and testing will be considered. Specifications should provide sufficient
constraints on interfaces and implementation characteristics to ensure that
compliance can be unambiguously assessed through both manual inspection and automated testing.
6. Specific Requirements on Proposals
The specific requirements described in this chapter are organized as follows: The
problem statement (chapter 6.1) describes some background and introduces
basic terms needed for further understanding. Chapter 6.2 approaches the scope
of the Workflow Management Facility’s functional requirements. The intention of
Chapter 6.3 (Relationship to existing OMG Specifications) is to point out to po-
tential respondents that the specification of the Workflow Management Facility has to take existing OMG Technology into account. Chapter 6.4 provides pointers to
related documents and standards, chapters 6.5 through 6.7 describe mandatory
and optional requirements and issues to be discussed.
Statement
6.1 Problem
A major goal of information technology is the effective support of a com pany’s
processes. Usually, this is achieved by designing, hardcoding and deploying a
system that (hopefully) covers all the functionality needed to support the pro cess
at the time of deployment. This approach has turned out to be in flexible, because
every change in the process requires a reconfiguration, or even worse, a re-imple-mentation of the related components.
Workflow management systems were developed to provide more flexibility. The
basic idea is to define workflow schemas describing the activities that should be
executed to support a process. With workflow management systems it is possible
to break monolithic applications into more reusable components and interconnect
these components in a very dynamic manner: Instead of program-code, a
workflow schema is used to explicitly represent the dependency between the
components.
Enterprises and virtual enterprises often use different workflow management pro-
ducts. It is essential that these workflow management products interoperate such
that a process can be defined and enacted from a collection of workflows that
span the products. A common set of interfaces to enable this interoperation
between the different products is required.
6.2 Scope of Proposals Sought
The Workflow Management Facility should provide for the manipulation and
execution of workflow instances, and optionally for the definition and management of workflow schemas that are used to define these workflow instances.
Submissions should be aware that the Common Facilities Task Force and the
Business Objects Domain Task Force are planning to coordinate workflow and
business objects both at the metamodel and the supporting infrastructure level.
6.3 Relationship to Existing OMG Specifications
The Workflow Management Facility potentially depends on the following OMG
Technology:
? OMG Interface Description Language (IDL): All interfaces of the Workflow Management Facility shall be described in IDL.
? OMG Transaction Service (OTS) - in order to be able to implement trans-actional secure workflow execution.
? OMG CORBA Security - see 5.2.3.
? OMG Systems Management Facility - in order to realize logically centralized control of active workflow instances.
The list above does not contain references towards the rich set of CORBA-
services. They might also be of great use but are not considered further. Never-
theless, submitters are obliged to use them where appropriate.
6.4 Related Documents and Standards
Object Management Group, "Common Facilities RFP-4 (Common Business
Objects and Business Object Facility)", TC Document 96-01-04
Object Management Group, "Common Facilities RFP-5 (Meta-Object Facility)", TC Document cf/96-02-01 R2, 5/13/96
Object Management Group, "Electronic Commerce DTF", Draft RFP-2, OMG-
Document ec/97-02-01
Object Management Group, "Defining the Workflow Facility", Presentation by
Marc-Thomas Schmidt to the Common Facilities Task Force, November 1996,
OMG-Document cf/96-11-03
Object Management Group, "Towards an OMG-style Workflow Facility",
Presentation by Wolfgang Schulze to the Common Facilities Task Force,
January 1997, OMG-Document cf/97-01-22
Object Management Group, "Product Data Management Enablers RFP (MFG
RFP1)“, OMG-Document mfg/96-08-01
Object Management Group, Responses to BODTF RFP-1
Workflow Management Coalition: "Workflow Facility Specification", Document
Number WFMC-TC-2101, Draft 0.6, 8 March 1997 , Internal Working Draft, cf/97-
03-13
Workflow Management Coalition: "Terminology & Glossary", Version 2.0, June
1996, Document Number WFMC-TC-1011
二次开发培训文档 一、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)
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
5.3与实例运行相关的事件 事件类型:EventHandler
Ora E-B O RA Wor Author: MSN: Creation Last Up Docume Version Approv
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.
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 元数据表的详细说明， -----------------------------------------------------------------------
导航 ?首页 ?日志 ?相册 ?音乐 ?收藏 ?博友 ?关于我 日志 小翼 程序员就像男人,语言就像女人,每个男人都想要很多女人,却很少有男人能真正了解一个女人,因为男人总是朝三暮四,而女人每天都在变,甚至有些是经过变性和整容的。 加博友关注他 最新日志 ?飘荡 ?游走... ?过客.. ?...记录 ?拯救... ?迷失? 该作者的其他文章
博主推荐 相关日志 随机阅读 首页推荐 ?俄监狱举办选美大赛 ?街拍“大宋”美女游郑州 ?韩女星遗书曝被迫卖身 ?我在美国野外露营装备 ?为毛泽东看病的六大御医 ?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调试器调试你的工作流
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上的所有包集用表示。对于一个包的明确显示，一个注释类
工作流引擎（Workflow Engine ） 所谓工作流引擎是指workflow作为应用系统的一部分，并为之提供对各应用系统有决定作用的根据角色、分工和条件的不同决定信息传递路由、内容等级等核心解决方案。 工作流引擎（Workflow Engine ） 什么是工作流引擎（Workflow Engine ） 例如开发一个系统最关键的部分不是系统的界面，也不是和数据库之间的信息交换，而是如何根据业务逻辑开发出符合实际需要的程序逻辑并确保其稳定性、易维护性（模块化和结构化）和弹性（容易根据实际业务逻辑的变化作出程序上的变动，例如决策权的改变、组织结构的变动和由于业务方向的变化产生的全新业务逻辑等等）。 Workflow 引擎解决的就是这个问题：如果应用程序缺乏强大的逻辑层，势必变得容易出错（信息的路由错误、死循环等等）。 就好比一辆汽车，外表做得再漂亮，如果发动机有问题就只是一个摆设。应用系统的弹性就好比引擎转速方面的性能，加速到100 公里需要1 个小时（业务流程发生变动需要进行半年的程序修改）还能叫好车吗？引擎动不动就熄火（程序因为逻辑的问题陷入死循环）的车还敢开吗？ 工作流解决方案与传统管理软件的关系 传统的管理软件注重解决企业应用层现存的问题（例如提高企业的资源配置率或提高单一员工的生产效率）。例如：EXCEL 可以提高员工画表格的效率、财务软件可以规范财务人员的工作并提高账目查询的效率、CRM 可以规范客户管理从而使客户资源掌握在公司手中而不是被一部分业务人员把持并提高客户响应时间、ERP 解决的是如何配置企业资源：使企业的人力资源、财力资源和物资资源能够根据业务的需求实现最大化配置。workflow 关注的是如何缩短流程闲置时间，从而提高企业的业务处理能力并使企业能够关注于真正对企业有意义的增值业务上。从建立企业神经系统的角度也许更能理解两者的区别。传统软件不能解决工作流的问题，例如ERP 关注的是企业的资源配置，但不可能解决资源传输过程中的损耗和降低传输（流程）的成本；同样workflow也不能完全解决传统管理软件所能解决的问题，例如对生产管理的MRP 系统所能解决的生产过程控制通过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的全部处理人（甘肃机制），路由图示说明如下：
报销流程开发概述
徐栋 微软金牌讲师 北京中达金桥技术服务有限公司
议程
? ? ? ? Windows i d Workflow kfl Foundation简介 d i 简介 报销流程概述 WF开发生态系统 总结
Windows Workflow Foundation
为微软产品及相关应用程序提供通用的工作流 设计平台和开发工具
? 统一的工作流技术 可用于Windows之上的所有应用 可用于跨应用场景 ? 重新定义工作流 构建以工作流为中心的可扩展框架及API 可用于Human和System的工作场景 ? 最核心的工作流框架 集成的开发环境/语言 Office12工作流引擎的基础部分 Microsoft Confidential 强大的 Partner支持
Windows Workflow Foundation
? 核心概念
A Workflow An Activity App Activity Library Workflow Foundation Base Activity Library ? workflow constructs Runtime Engine ? intrinsic behavior Runtime Services ? hosting flexibility Host Process ? my app or server
? Workflow是一组Activities ? Workflow在一个宿主应用 程序中运行：任意应用程序 或服务 ? 开发人员可以创建自己的 Activity库
? Base Activity Library：内 内 置的基本的Activity ? Runtime Engine：运行 Workflow与状态管理 ? Runtime Services：宿主 Workflow与通讯 ? Visual Designer：控件， 可以在应用程序中调用设计 Microsoft Confidential 器
? 组件
工作流包装 1.运行时包装 using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading; using System.Workflow.Runtime; namespace Nocturne.Workflow.Hosting { public class WorkflowRuntimeManager:IDisposable { private WorkflowRuntime _workflowRuntime; private Dictionary
手把手教你使用Gocad（实例） 1、首先通过DXF文件载入等高线，curve—9110、9120，由pointset mode生成等高点，如上图白色的点 2、通过wizards生成面 在surface creation中选择From data (without internal border) 3、点击creat outline curve from points和optiamize outline curve tobetter fit points,同时可以多次点击右侧的螺旋形按钮，多次优化；达到你满意的效果后，如果你需要保存生成outline就要在objects中进行重命名和保存。 4、点击creat surface来生成面，hide constraints用来隐藏不需要看到的contraints 5、上面就是生成的带有网格的等高面 6、将网格去掉（可以在attributes中去） 6、选择我们要载入其他的点（点必须是有坐标xyz），在生成我们向要的地层。在载入点后，curve mode—new—curvehull—of object来生成outline curve（这是另外一种生成outline curve的方法） 7、通过生成的outline curve和载入的点来得到一个面 8、这是生成的去掉网格以后的面 9、载入其他点，生成其他我们需要的面（古滑坡堆积体层） 9、宣威组滑带 10、现在我们来生成一个侧面，主要用来作为以后编辑切割其他地层的一个界面。在camera中仅显示等高面的outline courve，surface mode—new—build informs—tube 11、在expansion中键入你需要的值，如需要一个垂直的侧面则只修改Z值就可，同时选择twoway 从正负两个方向在延伸，这种方法还可以生成封闭的面（closed surface），选择seal ends即可 12、生成的侧面如图所示，白色的面是等高面的边界线 13、这时将刚才生成的洪积层、冰川堆积层、古滑坡面、宣威组滑带面和玄武岩层分别延伸surfacemode—border—expand--one
仅供个人参考 二次开发培训文档 一、ECOLOGY系统框架结构 1、主要的程序结构 Ecology For personal use only in study and research; not for commercial use Classbean 存放编译后的CLASS文件 js 系统中使用的JA VASCRIPT和VBSCRIPT脚本 Css 系统中JSP页面使用的样式 Images Images_face Images_frame 系统中使用的图片的存放目录 Crm Workflow 该功能分文件夹存放每个功能的文件 WEB-INF Prop 系统配置文件存放 Service 系统的接口配置文件的存放 二、说明一个JSP页面，一个JA VA程序的基本组成，如何阅读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)
泛微O A e c o l o g y二次开发实例开发完整 说明
二次开发培训文档 一、ECOLOGY系统框架结构 1、主要的程序结构 Ecology Classbean 存放编译后的CLASS文件 js 系统中使用的JAVASCRIPT和VBSCRIPT脚本 Css 系统中JSP页面使用的样式 Images Images_face Images_frame 系统中使用的图片的存放目录 Crm Workflow 该功能分文件夹存放每个功能的文件 WEB-INF Prop 系统配置文件存放 Service 系统的接口配置文件的存放 二、说明一个JSP页面，一个JAVA程序的基本组成，如何阅读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、JAVA程序的基本组成 在ECOLOGY中开发JAVA程序建议继承weaver.general. BaseBean，在 BaseBean中主要封装了两个方法：写日志文件，获取配置文件中的参 数值。 public String getPropValue(String fname , String key) public void writeLog(Object obj) 三、页面权限控制的说明,怎样在页面中引用权限，怎么样新增一个权限，如 何在新开发的模块上引入权限控制 在这一部分将描述：新增的页面如何保持和ECOLOGY的风格保持一 致；新增的页面上引用ECOLOGY中的权限；新增的页面上引用新的 ECOLOGY中还没有的权限； 1、可以根据<泛微协同商务系统(Ecology)_JSP式样编写指南>保证新开 发的页面在风格上和原有系统保持一致
Workflow简明教程 注：我们将通过作一个workflow的实例来演示一个workflow工作流的建立。 首先建立new的项目 在Workflows的file选择菜单中的选择向导选项，用向导作比较直观一些！ 选择后结果如下： 上面两个栏位是新建立的项目的名称internal name 是程序需要的名字，display是显示的名字。new process是项目中工作流过程的名称，同理，interal name是程序的名字，display name 是显示的名字 需要注意的是，internal name是能用中文的，而且最好用大写，display name没有要求 其余两个选项不作要求 输入你需要的名字然后点ok，这时你的workflow整体框架就出来了，如图： 左边是导航区，右边是工作区，
跟form的风格和相似，注意右边他默认了两个图标，这是workflow流的两个端点，start和end 。其中间的流过程是设计者来完成 下面我将作一个关于审核工作票的工作流，其流程图如下
第一步：我们要建立attribute ，即你在工作流中用到的所有的属性， 这个例子中要用到4个属性，分别是send (审核人)，view（修改人），gzpbg（工作票编号），p_url（打开的url地址）建立审核人，点右键，如图： 建立新的attrib属性 填写属性内容，注意如果是人员角色的属性，则要选择相对应的角色选项，如下 填写完毕，确定，然后同理创建其余3个属性， 这个时候属性创建完毕 第二步！创建流程的节点，也就是关键点 如图，我要创建一个审批的节点（p_check），还要创建一个审批不合格，需要重新审批的节点（p_ok） 在导航区的notification上点右键，新增节点