Difference between revisions of "Objects:X-BPMN Notations"
From EnterprisePLUS [E+]
m (Admin moved page Objects:X-BPMN Notations to Temp:X-BPMN Notations) |
|||
| (72 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | {{#lead: XbpmnNotations}} | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
[[Category:Objects]] | [[Category:Objects]] | ||
{{DISPLAYTITLE:X-BPMN Notations}} | {{DISPLAYTITLE:X-BPMN Notations}} | ||
Latest revision as of 07:01, 13 September 2016
Task Types
A Send Task is a simple Task that is designed to send a Message to an external Participant relative to the Process Once the Message has been sent the Task is completed The actual Participant which the Message is sent can be identified by connecting the Send Task to a Participant using a Message Flows within the definitional Collaboration of the Process A Send Task object shares the same shape as the Task which is a rectangle that has rounded corners However there is a filled envelope marker the same marker as a throw Message Event in the upper left ...
A Receive Task is a simple Task that is designed to wait for a Message to arrive from an external Participant relative to the Process Once the Message has been received the Task is completed The actual Participant from which the Message is received can be identified by connecting the Receive Task to a Participant using a Message Flows within the definitional Collaboration of the Process see Table A Receive Task is often used to start a Process In a sense the Process is bootstrapped by the receipt of the Message In order for the Receive Task to instantiate the ...
A User Task is a typical “workflow” Task where a human performer performs the Task with the assistance of a software application and is scheduled through a task list manager of some sort. A User Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a human figure marker that distinguishes the shape from other Task types (as shown in Figure 10.17).
A Manual Task is a Task that is expected to be performed without the aid of any business process execution engine or any application. An example of this could be a telephone technician installing a telephone at a customer location. A Manual Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a hand figure marker that distinguishes the shape from other Task types (as shown in Figure 10.17).
A Manual Service is when the service is performed by a human.
An Automated Service can be either an application service, data service, platform service, infrastructure service or a web service.
An Automated Task is an activity that is automated through either a business process execution engine or any application (e.g. using application features and/or functions to enable the application task).
Reporting is the exposure, description and portrayment of specific tasks, services and the associated information and data.The information and data objects/source can bind with the reporting activity the process components to the specific cockpits,dashboards or scorecards.
Mapping activities includes identifying, defining and plotting the involved business, information and data objects within theactivities. This allows to identify possible grouping of common business, information and data objects and their associatedrules (e.g. rulesets), enabling the change of complex objects and views into more simple views.
A Decision Table defines decisions based on a number of given conditions and actions. Decision tables allow to work from the same information, and are therefore a precise way to model complicated logics and associations.
An instance of a message delivered to one or more recipients. A Notification activity sends a message to a user, both therecipients and the content that needs to be specified. Notification activities furthermore allow flow rulesets to be applied inorder to notify users of events that occur during the workflow.
A Script Task is executed by a business process engine The modeler or implementer defines a script in a language that the engine can interpret When the Task is ready to start the engine will execute the script When the script is ompleted the Task will also be completed A Script Task object shares the same shape as the Task which is a rectangle that has rounded corners However there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Script Task see Figure A Script Task is a rounded corner ...
A Rule is a statement describing a business policy or decision procedure. Some programming languages run business rules together in very complex algorithms. In business process analysis, each rule is usually stated independently, in the general format of: If A and B, Then C.
A Rule Script allows generating a rule in a scripting environment. This is done through the connection of other activities andthe rules that govern these relations, and the actions between them. Rule scripts can furthermore be used with script types,and thereby automated test rules (e.g. configurable, programmed, query and event-based network alerts). The link betweenrule scripts and the mentioned script type could be used as artefact–based query that can be run against backend tables ordatabase views.
A Ruleset is a collection (and thereby a grouping) of rules. They are either grouped based on common related rules, decisions tables or the need to govern a specific set or behavior of tasks. Grouping such rulesets allows for sharing of rules and execution by a rules engine.
Rule Flows are comprised of linked tasks that contain the instructions for which rules to execute and in what order The rulesare organized into tasks and the rule flow specifies how tasks are chained together how when and under what conditionsthey are executed When you are dealing with many large rulesets managing the order in which rules are evaluated canbecome complex Rule flows allows you to specify the order in which rulesets are to be evaluated It does so by providing youwith a flow chart Use this chart to define which rule sets should be evaluated in sequence and which ...
A Flow Ruleset is a collection (and thereby grouping) of rules that apply to a flow. These flow rulesets are either grouped based on common related rules in the flow, decisions tables, or the need to govern a specific set or behavior of tasks in the flow. Grouping such flow rulesets allows for sharing of rules and execution, by a rule engine throughout the entire flow. As well as the relation to the reuse of such rulsets in other flows, starting from the main flow where the ruleset are applied.
Markers
Flows
The nature and behavior of Sequence Flows is described in Sequence Flow on page But there are special considerations relative to Sequence Flows when applied to Activities An Activity that is the target of multiple Sequence Flows participates in uncontrolled flow To facilitate the definition of Sequence Flow and other Process elements behavior we employ the concept of a token that will traverse the Sequence Flows and pass through the elements in the Process A token is a theoretical concept that is used as an aid to define the behavior of a Process that is being performed The behavior of ...
Objects
A Business Object is the term used to express real-world objects like people, employee, products or a sales order, customer and revenue. Business Objects used for example in business, process and service mapping and furthermore used in application implementations where they are used as a patented semantic layer that shields users from the complexities of information table names and data relationships.
Is a place where the real-world objects are stored.
Is an external input for the real-world objects. A kind of input parameter.
Is the real-world result of the entire process and or service flow. A kind of output parameter.
Represents a collection of real-world objects, e.g. a employee roles.
An Information Object is used to specify information about real-world objects (like people, employees, products or a salesorder, etc.), and is therefore a digital representation of an existing entity within an Information System (e.g. Oracle ERP or SAPERP). It encompasses both the business information (in the form of functions and methods) and the application information(in the form of attributes) of the entity. Information Objects can be found and therefore modeled in business functions,business services and business processes.
Is an external information input for the entire process. A kind of input parameter.
Is the information output/result of the entire process. A kind of output parameter.
Is a place where the information can be read or written (e.g. knowledge management or a filingcabinet). It persists beyond the lifetime of the process instance.
A Data Object is a logical cluster of all tables in the data set that have one or more columns containing data related to the same business entity. Data objects are not maps, but instead represent an object view of related Information Objects and they represent Business Objects.
Is an external data input for the entire process. A kind of input parameter.
Is the data result of the entire process. A kind of output parameter.
Is a place where the process can read or write data (e.g. a database or a filing cabinet). It persists beyond the lifetime of the process instance.
Represents a collection of data tables/columns containing data related to the same data entity (e.g. a list of order items).
Gateways
The Gateway controls the flow of both diverging and converging Sequence Flows. That is, a single Gateway could have multiple input and multiple output flows. Modelers and modeling tools might want to enforce a best practice of a Gateway only performing one of these functions. Thus, it would take two sequential Gateways to first converge and then to diverge the Sequence Flows.
The Event-Based Gateway represents a branching point in the Process where the alternative paths that follow the Gateway are based on Events that occur rather than the evaluation of Expressions using Process data as with an Exclusive or Inclusive Gateway A specific Event usually the receipt of a Message determines the path that will be taken Basically the decision is made by another Participant based on data that is not visible to Process thus requiring the use of the Event-Based Gateway For example if a company is waiting for a response from a customer they will perform one set of ...
Inclusive Gateways are used for modeling points of synchronization of a number of branches not all of which are active after which one or more alternative branches are chosen within a Choreography flow For example one of more branches MAY be activated upstream in parallel depending on the nature of goods in an order e g large orders fragile goods orders orders belonging to pre-existing shipment contracts and these are subsequently merged The point of merge results in one or more risk mitigating outcomes e g special insurance protection needed special packaging needed and different container categories needed Inclusive Gateways ...
A diverging Exclusive Gateway (Decision) is used to create alternative paths within a Process flow. This is basically the “diversion point in the road” for a Process. For a given instance of the Process, only one of the paths can be taken. A Decision can be thought of as a question that is asked at a particular point in the Process. The question has a defined set of alternative answers. Each answer is associated with a condition Expression that is associated with a Gateway's outgoing Sequence Flows.
Parallel Gateways are used to create paths and are performed at the same time, within a Choreography flow. For details of how Parallel Gateways are used within an Orchestration Process see page 293. Since there is no conditionality for these Gateways, they are available as-is in Choreography. They create parallel paths of the Choreography that all Participants are aware of.
The Parallel Event Gateway is also a type of race condition. In this case, however, when the first Event is triggered and the Process is instantiated, the other Events of the Gateway configuration are not disabled. The other Events are still waiting and are expected to be triggered before the Process can (normally) complete. In this case, the Messages that trigger the Events of the Gateway configuration MUST share the same correlation information.
Complex Gateways can model partial merges in Business Processes where when some but not all of a set of preceding branches complete the Gateway fires This can be considered the discriminator n-of-m join pattern and is not supported through the inclusive OR merge since it is not concerned with sets of branches but rather branches that have tokens Applied in Choreographies Complex Gateways can model tendering and information canvassing use cases where requests are sent to participants who respond at different times Consider an e-tender that sends a request for quote to multiple service providers e g warehouse storage in ...
