Understanding User-Defined Process Models
A User-defined process model contains these major components:
1. The Graphical Layout of the Process Model
This contains the process diagram with nodes and the link between the nodes. The data that defines the nodes and the links between the nodes is derived from one of these sources:
-
A boilerplate, which is a pointer to one of six tables in JD Edwards EnterpriseOne with data that implies a business process. Those six boilerplates are:
Boilerplate Table Usage Case Status Rules Table F1751 Case Management process Expense Reimbursement Routing Rules F09E110 Expense Management process HomeBuilder Activity Rules F44H002 HomeBuilder process Order Activity Rules F40203 Order to Cash (Sales Orders) or Procure to Pay (Purchase Orders) process Registration Activity Rules F1732 Asset Registration process W. O. Status Action Table F4826 Work Order process -
The Process Definition application (P00201), which you can use to create a custom definition of nodes and links.
If you use the Process Definition application to define a custom process, complete that task, as described in Chapter 4. “Defining a Custom Process,” before you begin designing the enterprise process in Enterprise Process Manager.
2. Filters
Design Option: A filter over the data that applies generally across the process model—a hard-coded “boundary”—which the user cannot change at runtime. For example, if you decide that the Order-to-Cash process will be based on tracking Stock items on Sales Orders, then the Design Options “Document Type = SO” and “Line Type = S” are used to establish the process, and they cannot be altered at runtime. The design options are displayed in the Design Option tab.
Runtime Option: A filter over the data that you establish so that the user can change it at runtime. For example, if you establish Runtime Options for Company, Business Unit, and Date, then the user can modify these filters at runtime if "Allow Override" is enabled for this filter, or accept the defaults that you defined for the process model. The runtime options are displayed in the Data Filtering and Grouping Options tab.
When you define data filters, you can also allow those filters to designate grouping of data. This enables your users to view the data in the process model by different dimensions. For example, you could define “Company” or “Order Date” as data filters. If you also choose to allow those filters for grouping, then your users can use the “View By” drop-down list (in the Analytics Options tab) in Enterprise Process Modeler to easily navigate through the data by those dimensions, for example, Company 1, Company 2, Company 3, and so on.
See Using the Show Analytics Option.
Common Design Practice: When defining filters for metrics and analytics, apply a consistent set of filters across all metrics and analytics. In the Default Value field, use consistent entries, map to consistent input parameters, or reference the appropriate runtime or design-time options as needed.
3. Metrics and Analytics
Metrics are numbers associated with the nodes and links on a process model.
Analytics are data visualizations, such as pie charts, bar graphs, and line graphs, that are contextually related to nodes, links, or the process as a whole.
Metrics and analytics are derived from these three components:
- A source of the data. The data can come from:
- A JD Edwards table
- A JD Edwards business view
- The output of a logic extension or an orchestration (analytics only)
- Filters over the data, either from design options or runtime options or static values (configured at design time).
- Aggregations of the data, such as counts, sums, or averages. This applies to table or business view only.
- A grouping of the data that ties it to a specific node or link. For example, if the nodes in the process model represent statuses of sales orders, then the data should be grouped by Status.