Opcenter Execution Foundation 4.

Extensibility Guide

04/2021
PL20201124062203470
Guidelines
This manual contains notes of varying importance that should be read with care; i.e.:
Important:
Highlights key information on handling the product, the product itself or to a particular part of the documentation.
Note: Provides supplementary information regarding handling the product, the product itself or a specific part of
the documentation.
Trademarks
All names identified by ® are registered trademarks of Siemens AG.
The remaining trademarks in this publication may be trademarks whose use by third parties for their own purposes
could violate the rights of the owner.
Disclaimer of Liability
We have reviewed the contents of this publication to ensure consistency with the hardware and software
described. Since variance cannot be precluded entirely, we cannot guarantee full consistency. However, the
information in this publication is reviewed regularly and any necessary corrections are included in subsequent
editions.
Security information
Siemens provides products and solutions with industrial security functions that support the secure operation of
plants, systems, machines and networks. In order to protect plants, systems, machines and networks against
cyber threats, it is necessary to implement – and continuously maintain – a holistic, state-of-the-art industrial
security concept. Siemens’ products and solutions only form one element of such a concept.
Customer is responsible to prevent unauthorized access to its plants, systems, machines and networks. Systems,
machines and components should only be connected to the enterprise network or the internet if and to the extent
necessary and with appropriate security measures (e.g. use of firewalls and network segmentation) in place.
Additionally, Siemens’ guidance on appropriate security measures should be taken into account. For more
information about industrial security, please visit https://www.siemens.com/industrialsecurity.
Siemens’ products and solutions undergo continuous development to make them more secure. Siemens strongly
recommends to apply product updates as soon as available and to always use the latest product versions. Use of
product versions that are no longer supported, and failure to apply latest updates may increase customer’s
exposure to cyber threats.
To stay informed about product updates, subscribe to the Siemens Industrial Security RSS Feed under https://
www.siemens.com/industrialsecurity.

Siemens AG PL20201124062203470 Copyright © Siemens AG 2021

Digital Industries 20210407_181048 Technical data subject to change
Postfach 48 48
90026 NÜRNBERG
GERMANY
Table of Contents
1 Essentials to Approaching Extensibility in Opcenter Execution Foundation.... 5
2 Opcenter EX FN Architecture Basics.................................................................... 6
2.1 Extensibility common concepts in Opcenter EX FN .................................................................8
3 Extensibility in Opcenter EX FN at a glance ...................................................... 11
3.1 How to Customize a Specific Opcenter EX FN Functionality .................................................11
3.1.1 Sizing Functional Blocks and Apps ....................................................................................................................... 12
3.1.2 The Daisy Paradigm ............................................................................................................................................... 14
3.1.3 Extending an Opcenter EX FN Functionality......................................................................................................... 14
3.1.3.1 Extending Entities with custom Properties .......................................................................................................... 15
3.1.3.2 Extending Command Applicability ....................................................................................................................... 16
3.1.3.3 Extending Command Behavior ............................................................................................................................. 17
3.1.3.4 Restricting Command Applicability ...................................................................................................................... 18
3.1.3.5 Restricting Command Behavior ............................................................................................................................ 18
3.1.4 Architecture Do's and Don'ts................................................................................................................................. 19
3.1.5 Data Model Do's and Don'ts .................................................................................................................................. 21
3.2 How to Customize a Specific Manufacturing Use Case ..........................................................24
3.3 How to Customize your Solution ............................................................................................24
3.3.1 Configuring Business Logic from Solution Studio................................................................................................ 25
3.3.2 UI Development and Extension............................................................................................................................. 25

Opcenter Execution Foundation 4.1 - Extensibility Guide iii

 ID OpcenterEXFN_ExtensibilityGuide

Title Extensibility Guide

Product Title Opcenter Execution Foundation

Version Title 4.1

Product Version OpcenterEXFN_4.1.0.0

Category Development, Configuration

Summary Provides detailed information on how to customize and extend

the Opcenter Execution Foundation functionalities provided by
default.

Audience Developer, System Integrator, Support Engineer, Project Engineer

Revision PL20201124062203470

State Published

Author Siemens AG

Language en-US

4 Opcenter Execution Foundation 4.1 - Extensibility Guide

 Essentials to Approaching Extensibility in Opcenter Execution Foundation

1 Essentials to Approaching Extensibility in Opcenter Execution

Foundation
Customization or extension is necessary whenever what is provided by default in Opcenter Execution Foundation
does not completely satisfy your project's requirements, and you want your project to evolve on the same
principles as Opcenter Execution Foundation.
Possible scenarios for project-oriented extensions may be:
• A new functionality not contemplated in Opcenter Execution Foundation needs to be implemented.
• An existing functionality provided by the product needs to be extended so that it satisfies your particular needs.
• You need new User Interfaces, not only to present a different layout, but also to display primarily runtime data
aggregated in a different manner.
• Existing User Interfaces need to be extended to manage a vaster or different set of information.
• The toggling of the available artifacts, such as Post-Actions and Pre-Checks, and the configuration of the UI
modules.

Who can perform customizations

Customization should be approached only by expert users who possess in-depth knowledge of Opcenter Execution
Foundation.
Therefore, we strongly suggest that you consult the Opcenter Execution Foundation Development and Configuration
Guide and the Opcenter Execution Foundation User Manual.
Furthermore, to approach customization, you must be familiar with how Opcenter Execution Foundation is
structured.

What tools are necessary to perform customization?

The required tools depend on the level at which you want to customize Opcenter Execution Foundation.
Generally speaking, you must be familiar with:
• Project Studio
• Solution Studio.

Opcenter Execution Foundation 4.1 - Extensibility Guide 5

Opcenter EX FN Architecture Basics

2 Opcenter EX FN Architecture Basics

Opcenter Execution Foundation provides you with a predefined Data Model, Business Logic and UI screens to be
used as a starting point for developing and configuring a dedicated project that suits your needs. The product
consists of:
• A set of Apps which reference the Functional Blocks provided by default. Each App includes:
• a Public Object Model (POM) consisting of the published artifacts of the Functional Blocks and their
relationships;
• a set of composite commands that make it possible to use commands belonging to Functional Blocks
of different domains in combination;
• a set of Opcenter Execution Foundation UI Components and UI Modules (including some MDUI Modules).
• Some Extension Apps, which extend the functionalities provided by the Foundation Apps.
• A set of Functional Blocks, which are grouped by the Data Model Domain to which they belong. Each Functional
Block contains the artifacts (entities, events, parameter types and, most importantly, commands) necessary to
fulfill a certain generic or manufacturing functionality.

Apps and Extension Apps

The following table lists the Apps, Extension Apps and the referenced Functional Blocks provided by Opcenter
Execution Foundation.

App Name Topic Referenced Functional Blocks

Application Log Application Logs related to • Siemens.SimaticIT.ALG_MS

installed Apps, Functional • Siemens.SimaticIT.ALG_OP
Blocks and Extension Apps

Audit Trail Audit Trail and Electronic • Siemens.SimaticIT.ES_SD

Signature • Siemens.SimaticIT.UDM_RF
• Siemens.SimaticIT.ES_MS

Automation Automation Gateway • Siemens.SimaticIT.ATN_MS

• Siemens.SimaticIT.ATN_OP
• Siemens.SimaticIT.UDM_RF
• Siemens.SimaticIT.AGW_MS

Barcode Barcode Rules Management • Siemens.OpcenterEX.FN.BRC_MS

• Siemens.OpcenterEX.FN.BRC_OP
• Siemens.SimaticIT.UDM_RF

BPFlow • Business Process Flows • Siemens.SimaticIT.BPF_MS

• Work Processes • Siemens.SimaticIT.BPF_OP
• Siemens.SimaticIT.UDM_RF
• Siemens.SimaticIT.TSK_MS
• Siemens.SimaticIT.TSK_OP
• Siemens.SimaticIT.EQU_MS
• Siemens.SimaticIT.EQU_OP

Data Segregation Data Segregation • Siemens.SimaticIT.DSG_SD

Defect Failure and Quality Action • Siemens.OpcenterEX.FN.DEF_MS

Management • Siemens.SimaticIT.UDM_RF

6 Opcenter Execution Foundation 4.1 - Extensibility Guide

 Opcenter EX FN Architecture Basics

App Name Topic Referenced Functional Blocks

Equipment Equipment • Siemens.SimaticIT.UDM_RF

• Siemens.SimaticIT.EQU_MS
• Siemens.SimaticIT.EQU_OP

Label Label Management • Siemens.SimaticIT.LBM_MS

• Siemens.SimaticIT.LBM_OP

Material • Material Templates • Siemens.SimaticIT.MAT_MS

• Material Groups • Siemens.SimaticIT.MAT_OP
• Materials • Siemens.SimaticIT.UDM_RF
• Siemens.SimaticIT.EQU_MS
• Siemens.SimaticIT.EQU_OP

OPCUAConnect Connection between • Siemens.SimaticIT.OPCUAConnect_MS

Equipment and shop-floor • Siemens.SimaticIT.OPCUAConnect_OP
(Extension of
devices via Automation
Equipment App)
Gateway

Personnel Personnel and users • Siemens.SimaticIT.PRM_MS

• Siemens.SimaticIT.DSG_SD

QEMigration Migration of existing Failures • Siemens.OpcenterEX.FN.QEMigration_MS

from Work Instruction App • Siemens.OpcenterEX.FN.DEF_MS
(Extension of Defect
to Defect App. • Siemens.SimaticIT.CHR_MS
App)
• Siemens.SimaticIT.UDM_RF

Reference • Units of Measure • Siemens.SimaticIT.UDM_RF

• State Machines

Signals Signals • Siemens.SimaticIT.SGN_MS

• Siemens.SimaticIT.UDM_RF

System Manages base entities and • Siemens.SimaticIT.SITUASys

functionalities

Task Tasks • Siemens.SimaticIT.UDM_RF

• Siemens.SimaticIT.TSK_MS
• Siemens.SimaticIT.TSK_OP
• Siemens.SimaticIT.EQU_MS
• Siemens.SimaticIT.EQU_OP

Opcenter Execution Foundation 4.1 - Extensibility Guide 7

Opcenter EX FN Architecture Basics

Extensibility common concepts in Opcenter EX FN

App Name Topic Referenced Functional Blocks

WITask Management of Task • Siemens.SimaticIT.EQU_MS

Definitions and Task • Siemens.SimaticIT.EQU_OP
(Extension of Work
Instances of Work • Siemens.SimaticIT.ES_MS
Instruction App)
Instruction Task type. • Siemens.SimaticIT.ES_SD
• Siemens.SimaticIT.TSK_MS
• Siemens.SimaticIT.TSK_OP
• Siemens.SimaticIT.UDM_RF
• Siemens.SimaticIT.WI_MS
• Siemens.SimaticIT.WI_OP
• Siemens.SimaticIT.WI_TSK_MS
• Siemens.SimaticIT.WI_TSK_OP
• Siemens.SimaticIT.CHR_MS
• Siemens.SimaticIT.CHR_OP

Work Instruction • Work Instructions • Siemens.SimaticIT.UDM_RF

• Quality Execution • Siemens.SimaticIT.WI_MS
• Siemens.SimaticIT.WI_OP
• Siemens.SimaticIT.ES_SD
• Siemens.SimaticIT.ES_MS
• Siemens.SimaticIT.CHR_MS
• Siemens.SimaticIT.CHR_OP

Functional Blocks
Foundation Functional Blocks can be found at Overview of Functional Blocks in the Opcenter Execution
Foundation Development and Configuration Guide.

2.1 Extensibility common concepts in Opcenter EX FN

Opcenter Execution Foundation comes provided with a group of building blocks known as artifacts, which you can
combine to form your solutions.
Some artifacts are software modules that you can develop in Project Studio (programmable artifacts), whereas
others can be authored as aggregates of smaller artifacts in Solution Studio (compound artifacts).

Programmable Artifact Programmable Artifact Description

Entities and Facets Define the static Data Model, deciding the degree of independence you need to
give to your model participants and the relationships among them.

Command Handlers Define the way the database or external systems will be changed according to a
request.

Event Handlers Define the reaction to changes in the system.

Model-Driven and Define how users can manipulate entities.

Standard UI Modules

UI Components Define the building blocks for complex interfaces.

8 Opcenter Execution Foundation 4.1 - Extensibility Guide

 Opcenter EX FN Architecture Basics

Extensibility common concepts in Opcenter EX FN

Compound Artifact Role in Extensibility

UI Applications Define how the solution will be available to a group of user, choosing the right
User Interfaces that Apps make available.

Process Definitions Author a Business Process, deciding how Task Types must be orchestrated.

Mashups Build up complex interfaces.

Signal App Provides the environment where it is possible to manage Signal Rules
representing a one-to-one relationship between a trigger and the logic that must
be activated.

Programmable Artifacts are not static, but rather, are conceived to be expanded, thanks to elements coming from
different Functional Blocks. They apply to specific contexts and adopt a variety of extensibility techniques.

Extensibility Techniques
Programmable Extensibility Applicability
Artifact Technique

Entities and Facet Use a Facet when you want to extend an entity with properties that
Relationships are relevant to a specific technological field.
Facets do not support relationships to single instances ("to-1"
relationships).

Entity as Facet Use an entity in a "1-to-1" relationship with the base entity when
you need to establish "to-1" relationships with other entities
("1-to-1")
(belonging to the same logic domain) in order to enforce their
relationships.

Child Entity Use a Child Entity when you are need to add a "1-to-many"
relationship between the base entity and a list of one or more
("1-to-many")
items.

Command Post-Action Adopt Post-Actions when you want to extend Command Handlers
Handlers with a transactional continuation in another technological field.
Post-Actions accept the same input parameters as the command to
which they are attached and cannot change the command's
output: however, they can make the command fail transactionally.
It is possible to sort Post-Actions and to disable them according to
the needs of your business logic, provided that they are not
mandatory.

Opcenter Execution Foundation 4.1 - Extensibility Guide 9

Opcenter EX FN Architecture Basics

Extensibility common concepts in Opcenter EX FN

Programmable Extensibility Applicability

Artifact Technique

Pre-Check Adopt Pre-Checks when you realize that you have constraints from
a different technological field that make using the base command
inapplicable or forbidden.
Pre-Checks cannot change entities, call commands and fire events,
they can just access the reading model.
Although not essential to your business logic, it is possible to sort
Pre-Checks to improve performance. You can also disable one or
more Pre-Checks, according to your needs.

Event Continuation Adopt Event Continuation to model a consequence following an

event that has taken place. The relationship that is established is
one of cause-effect.
To allow Event Continuation, you should issue a "fire on commit"
event to signal to the subscribed observers that something has
taken place.
It is not possible to sort Event Handlers but it is possible to
configure a sequential execution.

Event Handlers Event Adopt Event Orchestration to model a consequence following an

Orchestration event that has taken place within an App. The relationship that is
established is one of cause-effect, not affected by other indirect
causes.
Event Handlers are usually implemented in the destination App, as
they manage how a subsystem reacts to a change in the system
status.

Model-Driven User Model-Driven User If you do not need to customize the master page of an MDUI, you
Interfaces Interface Extension can extend it by implementing an extension that will show
additional data. In addition, you can add custom commands to the
command bar both in Master pages and Master and Detail screens.

There exist common situations in which Extensibility is not feasible: in such cases, you must resort to implementing
new artifacts either from scratch or from the copy of an existing artifact.

10 Opcenter Execution Foundation 4.1 - Extensibility Guide

 Extensibility in Opcenter EX FN at a glance

How to Customize a Specific Opcenter EX FN Functionality

3 Extensibility in Opcenter EX FN at a glance

The power of Opcenter Execution Foundation resides in its possibilities regarding customization, which can be
performed on three distinct levels: fine, intermediate and general.
The following table presents what can be customized, starting from the lowest level, using a "bottom-up"
approach.
Click the corresponding link to view the process/procedure for each specific level of customization:

Customization Level What it refers to...

Fine A specific functionality: in this case, the existing artifacts and behaviors
are typically customized or extended. Typically, this is achieved by
extending an existing Functional Block or creating a new one.

Intermediate An entire use case: According to the business needs, the authoring of
Signal Rules, Business Process Flows, Task Types and Mashups could be
involved.

General The complete solution: in this case, one or more UI Applications must be
configured, along with any other solution relevant configurations (such
as for example, the definition of the user access rights, database
maintenance, audit trails, and so on) to make the Apps and
functionalities available and the toggling of the handlers present at the
lower levels are involved.

Rules for achieving successful customization

• After performing Fine customization, you will necessarily have to perform Intermediate customization on the
entire use case and then General customization on the complete solution, so that the changes made to the
functionality will become effective.
• After performing Intermediate customization, you will necessarily have to perform General customization on the
complete solution, so that the changes made to the use case will become effective. Fine customization is not
required.
• General customization of the complete solution (for example, combining the provided functionalities in a
different way) does not require that you perform customization at the Fine and Intermediate levels, in order to
become effective.

3.1 How to Customize a Specific Opcenter EX FN Functionality

Customization at this level in Opcenter Execution Foundation involves working with Functional Blocks and the
artifacts contained therein: command handlers, event handlers, pre-checks, post-actions.

Available Customization Options

How customization can be carried out at this level depends on what is currently available in your project and what
you require.
Depending on your needs, you can choose to:
• Extend an Opcenter EX FN functionality.
• Add a new functionality by creating your own Functional Block from scratch, using Project Studio.
• Deliver your artifacts in Apps or Extension Apps that make your artifacts available to clients.

Opcenter Execution Foundation 4.1 - Extensibility Guide 11

Extensibility in Opcenter EX FN at a glance

How to Customize a Specific Opcenter EX FN Functionality

Workflow
In all cases listed above, you must:
1. Design your extension domain accurately.
2. Create and implement a new Functional Block according to the following workflow:

Note In the modeling phase, you may have to decide which technique to use.
3. Create and implement a new custom App according to the following workflow:

4. If you need to further customize the new custom App without having the source solution, create and implement
the related Extension App.
For more information, see How to Develop a Manufacturing Use Case (App) in the Opcenter Execution
Foundation Development and Configuration Guide.

3.1.1 Sizing Functional Blocks and Apps

Using Project Studio, you can extend the functionality provided by an Opcenter Execution Foundation Functional
Block belonging to a Domain (that is, belonging to Reference, Master Data or Operational Domain).
For instance, the Reference Domain contains fixed entities like State Machines, Units of Measurement,
Autonumbering, the Master Data Domain contains engineering configurations and the Operational Domain

12 Opcenter Execution Foundation 4.1 - Extensibility Guide

 Extensibility in Opcenter EX FN at a glance

How to Customize a Specific Opcenter EX FN Functionality

contains the runtime instances. For a detailed explanation, see the Data Model Domains in the Opcenter Execution
Foundation Development and Configuration Guide.
In this case, you must be aware of the structure of the artifacts involved in the functionality and how they can be
extended.
Opcenter Execution Foundation comes with a set of different Functional Blocks that are packaged into several
Apps. Each Functional Block contains the back-end functionality to provide a basic benefit, whereas Apps group the
Functional Blocks and User Interfaces necessary to provide a specific business benefit to a set of business scenarios.
The User Interfaces contained inside an App can be grouped to form a UI App. In this way, User Interfaces can be
offered to a specific final user.

Sizing custom Functional Blocks

Like Foundation Functional Blocks, custom Functional Blocks must be designed to contain the artifacts relative to a
single domain (that is, the Reference, Master Data or Operational Domain).
They function as pluggable wrappers containing business logic for a specific field.
For example, a Functional Block may contain the functionalities relative to a specific class of physical devices, or the
functionalities needed to enable integration with a specific Third Party.
User Domain Functional Blocks are those used for read operations on third-party databases: they can contain
native entities, and they wrap tables or views from external databases and their commands provide an interface to
an external system that can be accessed via APIs and can fire events.
When you are extending an existing Functional Block, you can use the sizing of the base Functional Block as your
starting point.

Sizing custom Apps

Apps represent basic packages which deliver functional capabilities and contain the user interfaces based on
existing Functional Blocks that are related to a specific business purpose.
An App ideally contains business value, meaning the software provided to solve an industrial problem.
An App can be seen as a pluggable software component.
The following artifacts are available in Apps:
• Reading Functions provide a more convenient access to data from non-relational sources.
• Custom Views provide a quick and maintainable aggregation of relational data.
• User Interfaces provide specific layouts.
• Choreography Event Handlers synchronize different Apps.
• Post-Action configurations enable and sort Post-Actions.
• Events/Signals.

Sizing custom Extension Apps

An Extension App is an ancillary artifact that extends or configures the artifacts delivered through the entry points
of another App.
You should define an Extension App when you need to refer to artifacts contained in the base App:
• Extending MDUI modules in the base App with MDUI extensions
• Calling Composite Commands belonging to the base App
• Extending Composite Commands with pre-checks and post-actions
• Creating additional views or publishing entities coming from Functional Blocks
You should use an Extension App also when you need to change the behavior of existing artifacts:

Opcenter Execution Foundation 4.1 - Extensibility Guide 13

Extensibility in Opcenter EX FN at a glance

How to Customize a Specific Opcenter EX FN Functionality

• Pre-Check configurations
• Event Handler subscriptions
• Post-Action configurations

3.1.2 The Daisy Paradigm

Opcenter Execution Foundation is not based on the traditional concept of layers, in which a component at a higher
level incorporates the components at a lower level. On the contrary, it is based on a pattern commonly known as
composition, where each contributor can add their extensions to the basic parts as petals that get connected to the
central disk of a daisy.

 Terminology
We refer to the composition pattern as the daisy extension paradigm or daisy pattern to avoid an overly
abused term and to immediately evoke the concept according to which components are combined.

The daisy extension paradigm has been chosen because it offers more freedom in combining extensions coming
from a vast catalog, while maintaining the possibility to receive updates and fixes of the central components.
The daisy extension paradigm is characterized by having one level of depth: all extensions must be attached to the
central structure.
The disk-petal relationship involves different objects in Opcenter Execution Foundation:
• An App can be extended by one level of Extension Apps.
• Entities can be extended by one level of Facets.
• Public Command Handlers can be extended by one level of Pre-Checks.
• Command Handlers can be extended by one level of Post-actions.
• MDUIs can be extended by one level of MDUI Extensions.

3.1.3 Extending an Opcenter EX FN Functionality

Anatomy of Business Logic
Business logic can be designed to follow a standard composite structure that makes it possible to customize
behavior inside Opcenter Execution Foundation:
• Pre-checks (optional)
• Command handlers
• Pre-executions (if any)
• Core (mandatory)
• Post-executions (if any)
• Post-Actions (optional)
Business logic consists in a transaction that can be invoked by other transactional handlers.
In detail, a business logic structure contains:
• A set of optional checks, the execution of which is ordered from the least restrictive (or efficient) to the most
restrictive (or efficient). Examples of pre-executions could be: the checks that must be performed on the input
parameters, the checks that you perform on the existence of an entity before performing the required
operations on it.
• A body that modifies the system status.
• A set of mandatory actions, the execution of which is ordered from the most restrictive (or efficient) to the least
restrictive (or efficient). Examples of post-executions could be: the operations performed on secondary entities,
operations to be traced in the history.

14 Opcenter Execution Foundation 4.1 - Extensibility Guide

 Extensibility in Opcenter EX FN at a glance

How to Customize a Specific Opcenter EX FN Functionality

 Information
Using Solution Studio, you can disable and sort Pre-Checks and Post-Actions.

Workflow
1. In Opcenter Execution Foundation Project Studio, create a new Functional Block that belongs to the same
domain as the Functional Block you want to extend.
2. Reference the product Functional Block from the Functional Block you have just created.
3. If necessary, reference the new Functional Block to other Functional Blocks.
4. In the Model project, define the artifacts (entities, commands, events, types and/or facets) necessary to
implement the logical and physical extension of the manufacturing functionality:
• Add properties to entities when the provided entities do not possess the properties you require.
5. Build your Model.
6. In the CommandHandler project, implement the logic to be executed by adopting one or more of the following
techniques:
• Extend command applicability when the provided commands cannot be applied to all the required cases
(that is, there are Pre-Checks blocking them).
• Extend command behavior when the provided commands are unable to change all the required entities
(that is, they need to modify more entities or trigger more actions).
• Restrict command applicability when the provided commands can be applied to more cases than
required (that is, you want your Pre-Check to block them).
• Restrict command behavior when the provided commands change more entities than required (that is,
they need to modify less entities or trigger less actions).
7. Configure and then generate the Functional Block package: the new Functional Block is ready to be included in
your App (or Extension App).

3.1.3.1 Extending Entities with custom Properties

When you have identified an existing entity as the base for your customization, you should leverage Facets to
extend its basic structure with the properties you require for certain usages.
Facets are ancillary artifacts to Entities described in Creating Facet Instances of the Opcenter Execution
Foundation Development and Configuration Guide, that permit appending the properties you need to the base
structure.

Opcenter Execution Foundation 4.1 - Extensibility Guide 15

Extensibility in Opcenter EX FN at a glance

How to Customize a Specific Opcenter EX FN Functionality

Constraints
In the following cases, Facets cannot be used:
• When your extension is not a single extension, but, rather, a list of related instances. In this case, it is
recommended that you use an entity linked to the existing entity (see Extension2 in the figure) by means of
composition. The logical key of the parent entity will be inherited from the child entity with the addition of the
local discriminator (in the figure, Base.NId with Extension2.LocalNId). For example, in Opcenter Execution
Foundation, AMPowderBatchGenalogy is a child entity for DM_MaterialTrackingUnit.
• When you need to establish an enforced "use" relationship with a Catalog instance (see Extension3 in the
figure), you may consider adding the new properties to an entity, rather than to a facet. For example, in
Opcenter Execution Foundation, DM_Material is modeled as an entity instead of a facet to be able to refer to
Functional Codes and Material Classes
• In this case, always bear in mind to handle the extension entity as if it were a facet: in particular, no field is to be
included as part of the logical key (so you will be implementing a ‘1-to-1’ relationship with the base entity) and
the extension entity must not be used in the "1" end of relationships with other entities.

Adapting the User Interface

When you have an existing MDUI managing the Base Entity, you can create an Extension App with one or more MDUI
Extensions to manage your extension. For more information, see How to Extend User Interfaces in an Extension App
in the Opcenter Execution Foundation Development and Configuration Guide.
Also see Data Model Do's and Dont's and UI Development and Extension.

3.1.3.2 Extending Command Applicability

In many cases, you may want to make it possible to use a certain Command in circumstances that would normally
prevent its execution.

16 Opcenter Execution Foundation 4.1 - Extensibility Guide

 Extensibility in Opcenter EX FN at a glance

How to Customize a Specific Opcenter EX FN Functionality

If a command structure contains Pre-Checks, you can disable one or more of them in the Extension App at hand that
contains the command to which they refer: in this case, the Extension App's requirements will be less restrictive.
For further information on Pre-Check management, see Configuring Business Logic from Solution Studio.

3.1.3.3 Extending Command Behavior

Extending the behavior of a Command means adding some continuations to it: for example, actions that affect and
modify other entities or trigger other artifacts.
When these continuations are just based on the parameters of the command and on the information already in the
database, and not on additional parameters, you can adopt one of these approaches:
• If the continuation is a part of the Command transaction necessary for its completion, you should use Post-
Actions and share the parameters and the result of the original Command. For details, see How to Extend
Business Logic with Post-Actions in the Opcenter Execution Foundation Development and Configuration Guide.
• If the continuation can be seen as an independent reaction to the final status of the command transaction, you
should adopt Event Continuation: you should subscribe to an event fired on the commit of the Command. At
this point, you should implement an appropriate Event Handler. The Event Handler will then call a custom
Command containing the desired logic for triggering the appropriate behaviors.
For more information see What Is an Event and What Is an Event Handler? in the Opcenter Execution
Foundation Product Overview and How to Implement Event Handlers in the Opcenter Execution
Foundation Development and Configuration Guide.
As an alternative to Event Handlers you can configure a Signal Rule, which represents a one-to-one relationship
between a trigger and the logic that must be activated. For the same trigger you can configure multiple Signal
Rules. The artifacts that can be used as trigger sources are entities, automation entities, or signals. For more
information see What Are Signal Rules? in the Opcenter Execution Foundation User Manual.
Event Continuation and Post-Actions can be seen as techniques to create a chain from the existing Command. The
differences between the two are in particular:
• Post-actions enlist in the same command transaction and their order of execution can be defined.
• Event Continuation consists in Event Handlers that are not enlisted in the same transaction and can be executed
in an indefinite order, unless sequential execution has been configured.
You can configure Post-Actions and Event Subscriptions from inside App Management. For details see Configuring
Command Settings and Configuring Event Subscriptions in the Opcenter Execution Foundation Development and
Configuration Guide.

Opcenter Execution Foundation 4.1 - Extensibility Guide 17

Extensibility in Opcenter EX FN at a glance

How to Customize a Specific Opcenter EX FN Functionality

Besides using FireEventOnCommit to allow Event Continuation in case of commit, you can fire a compensation
event using the FireEvent before returning an Execution Error to the main command chain to allow your
subscribers to be notified and compensate with appropriate measures.

Aggregate Properties
There are common cases, known as Aggregate Properties, in which a property of an entity at a higher level must be
changed after a change at a lower level: however, keep in mind that such cases do not always result in the changing
of the property of the higher-level entity.
For example, you may need to change the status of a Work Order depending on the status of its Work Order
Operations.
In this case, you need to adopt Event Continuation to be sure that the committed status of all concurrent
transactions at the lower level be read at least once.

 Transaction Isolation
Opcenter Execution Foundation works using an Optimistic Snapshot Isolation Level: transactions are not
enqueued, but executed simultaneously.
A snapshot of the system at the beginning of the transaction is taken and, if any other transaction has
modified the system at the commit instant, the current transaction will be immediately re-attempted.
Event Handlers and Signal Rules are not run in a single transaction. Therefore, their queries tend to read
data while being modified by another transaction. As a result, Event Handlers and Signal Rules may base
their decisions on uncommitted data.
The correct approach is to box decisions inside command handlers.

Extending a Command with Custom Parameters

When your additional execution needs more input parameters, it is not possible to rely on Post-actions or Event
Continuation.
One example is when additional parameters come from the user or from external systems. In that case, you must
wrap the Functional Block command in a new command exposing the additional parameters.

3.1.3.4 Restricting Command Applicability

You may want to restrict the use of a Command, preventing it from being used in certain circumstances so that it
returns an execution error and aborts the transaction.
You can add Pre-Checks to those Commands that you do not want to be available for execution when certain
conditions are present. They can be defined in the same Functional Block or in other Functional Blocks as well. For
details, see Modeling Pre-Checks in the Opcenter Execution Foundation Development and Configuration Guide.
They are enabled inside the Command Setting Configuration of an App / Extension App. In case of Extension App,
the configuration will just affect the Command when called through the base App. For details see Configuring
Command Settings in the Opcenter Execution Foundation Development and Configuration Guide.

3.1.3.5 Restricting Command Behavior

You may need to restrict the behavior of a Command so that it affects less entities or triggers less artifacts.

18 Opcenter Execution Foundation 4.1 - Extensibility Guide

 Extensibility in Opcenter EX FN at a glance

How to Customize a Specific Opcenter EX FN Functionality

Designing a variety of modular Apps and Functional Blocks allows you to install just the artifacts you require: for
instance, if you do not refer a Functional Block from any of the installed Apps, the Pre-Checks, Post-Actions and
Event Handlers contained in the Functional Block will not be run in your solution.
To modify the behavior of a Command safely, you must refer to its internal structure to locate the sections that
must be suppressed and, depending on their type, you can make the appropriate changes.

Section in Extension techniques

command
structure

Pre-Check If you want to disable a Pre-Check, you are extending the applicability of a command.

Pre-Execution None of the command's main sections can be disabled, but sometimes they can be undone
with an opposite command called in a Post-Action: note that all events will be fired at the
end of the entire transaction.

Sub-Command

Post-Execution

Post-Action Post-Actions are enabled when their Functional Block is loaded, but you can still disable
them, provided that they are not mandatory. For detailed information see Modeling Post-
Actions section in the Opcenter Execution Foundation Development and Configuration Guide.

In some cases, operating in Solution Studio, you can disable Event Handlers or change their subscriptions. If
subscriptions are created as default subscriptions, you cannot disable them, but only detach them from the worker
role.

3.1.4 Architecture Do's and Don'ts

When customizing or extending your project, you need to take into account important rules to be applied. The table
below summarizes the rules to be kept in mind before modifying the architecture of your project, specifying what
you can do and what not, according to the following legend:
Legend

Icon Meaning

Suggested

Forbidden

To be considered

To be avoided

Opcenter Execution Foundation 4.1 - Extensibility Guide 19

Extensibility in Opcenter EX FN at a glance

How to Customize a Specific Opcenter EX FN Functionality

Operation Do's/Don'ts

DO design a dedicated Functional Block for targeting a specific external system.

If you need to integrate a Third Party, first try to integrate it with native Functional Blocks, which
can provided by the external system.
A typical example used is the integration with an at-line control system exposing its own APIs
and having a Relational Database that can be read using reading functions. External systems
often refer to a single horizontal domain, so you may not require separate Functional Blocks for
Engineering and Runtime.

DO clearly identify dependencies and contact points between Functional Blocks.

When combining different Functional Blocks, let peripheral Functional Blocks depend on main
ones, and isolate only a few contact points so that your Functional Blocks are not tightly
coupled.
You can define tables that act as a bridge between different functional areas: for example, when
the evidence of an operation that encountered problems during production is also relevant for
the quality-tracking subsystem, you can devise a shared table containing the Master Data
relevant to both areas (also known as domain tag), such as "scratch" or "color drift" and you can
link it in both vertical domains.

DON'T extend Extension Apps.

According to the Daisy Paradigm, extensions are flat and should not be added to other
extensions to avoid compromising the solution's modularity. They work side by side.
For example, if you need to see your custom content with an existing MDUI Extension contained
in an Extension App, simply create your own Extension App on the same central App and extend
the base MDUI module.

CONSIDER sizing Functional Blocks so they can be plugged into as many scenarios as possible.
Imagine a set of real or fictitious scenarios where your Functional Blocks might be used (for
example, Aerospace, Repetitive, One-Piece-Flow, Formulation, Process) and think of the possible
combinations in which using the Functional Block can come in handy, as well as those in which it
can be left out. You should maximize the number of meaningful combinations and reduce the
overall number of Functional Blocks to a minimum.
For example, the Process Flow Control Functional Block manages process milestones for
Material Tracking Units belonging to different Materials: typical examples are vehicles in the
Automotive industry and sublots of bulk materials in the Composite Material industry. Keeping
such possible generalizations in mind makes it easier to group the artifacts belonging to the
Functional Block in a manner so that they are more reusable.

20 Opcenter Execution Foundation 4.1 - Extensibility Guide

 Extensibility in Opcenter EX FN at a glance

How to Customize a Specific Opcenter EX FN Functionality

Operation Do's/Don'ts

CONSIDER isolating the most particular, complex or unstable units of code in a distinct
Functional Block to facilitate their replacement and maintenance.
Sometimes, during the lifecycle of a project, it is necessary to integrate with subsystems that are
susceptible to change or instability. By wrapping these subsystems into dedicated Functional
Blocks, any possible side effects of this instability are potentially thwarted, because the
subsystems are not contained in Functional Blocks the contents of which are of more ample use.
Said subsystems can be a native part of your solution or injected.

CONSIDER designing a Functional Block with the same boundaries as those of the base when
you are extending artifacts from the Master Data Domain.
CONSIDER designing a Functional Block limited to a specific technological subject when you
are extending artifacts from the Operational Domain.
The simplest choice for organizing your extension artifacts (in particular, Facets, Relationships,
Post-Actions, Pre-Checks and DB-Init files) is to define your Functional Block with the same
extent as the base Functional Block.

AVOID creating Functional Blocks that refer solely to a specific project.

For example, do not create a MYPROJECT_Material Functional Block, which would end up
containing trial or incomplete functionalities over time: instead, try to characterize your business
with the capability you want to add to the existing solutions.

AVOID creating a Functional Block from scratch if you can start from an existing one.
Evaluate if you can extend an existing generic entity, rather than creating your own main entities.

3.1.5 Data Model Do's and Don'ts

When customizing or extending your project, you need to take into account important rules to be applied. The table
below summarizes the rules to be kept in mind before modifying the data model of your project, specifying what
you can do and what not, according to the following legend:
Legend

Icon Meaning

Suggested

Forbidden

To be considered

To be avoided

Opcenter Execution Foundation 4.1 - Extensibility Guide 21

Extensibility in Opcenter EX FN at a glance

How to Customize a Specific Opcenter EX FN Functionality

Operation Do's/
Don'ts

DO use physical extensions when all basic data-manipulation commands (such as Create, Update,
Delete: CrUD) and the User Interfaces use an existing entity structure for which a completely new
behavior is implemented. For more information, see the Opcenter Execution Foundation Product
Overview.
For example, in structural terms, Functional Code (for example, "steering wheel") is a Material
Group, but it participates in other relationships and works in a different way than in the Material
Group. This makes it easier for you to comprehend the database model.

DO adopt loose relationships (that is, relationships implemented on logical keys and not enforced
by a physical foreign key) not only when crossing a horizontal domain (for example, between
Operational and Master Data), but also when crossing a vertical domain boundary that you may
not require in your functionalities. Postpone consistency checks between domains to the last
opportune moment.
For example, if you are defining a whitelist of materials that are compatible with a section of your
process, you are dealing with a formulation or regulatory domain, and not with a procurement
domain: the business logic involving the whitelist will not be concerned whether a Material
Definition exists in the system, until some operational domain actually calls for it.
The benefits of this well-established Domain-Driven Design approach are:
• Greater modularity (more possibilities to combine/couple/decouple) that can be fine-tuned by
typically using Pre-Checks if coupling is required by the final industrial processes.
• Better comprehension from the final user's standpoint: for example, when functionalities rely
on internal relationships that are not clear from a functional perspective (for example, export).
• The possibility of Data Maintenance without being blocked by unnecessary relationships.

DON'T extend artifacts that are already being used as extensions.

According to the Daisy Paradigm, extensions are flat and should not be added to other extensions
to avoid compromising the solution's modularity. They work side by side.
For example, if you want to extend an entity that has already been extended using a facet, start
from the base entity and make your new functionality work only in relation to the basic structures.
Try to limit the degree to which your extensions are dependent on other extensions as mush as
possible.

DON'T append facets or entities to other facets or entities used for extension to implement a "1-
to-many" relationship: append them directly to the central entity.
If possible, avoid making functionalities on your child entities depend on facets or other child
entities: at least provide a default behavior in case the facets you require do not exist.

DON'T create two instances of the same facet type on the same record.
Always keep a "1-to-1" relationship per facet type between central entity and facet.
You cannot define keys on facets, so it is impossible to uniquely identify facets of the same type.
When you need to add children to an existing entity, use entities and link them with composition
to the parent entity.

22 Opcenter Execution Foundation 4.1 - Extensibility Guide

 Extensibility in Opcenter EX FN at a glance

How to Customize a Specific Opcenter EX FN Functionality

Operation Do's/
Don'ts

CONSIDER grouping facets that are used at the same time.

If cluster of information are consistently used together, find a viable compromise between
modularity and ease of access.

CONSIDER using an entity instead of a facet when you foresee performance issues.
Always treat entities used for extension as if they were facets: do not attach other entities or facets
to them, but to their central entity.

CONSIDER using an entity instead of a facet when you need to refer to entities with a "to-1"
enforced relationship.
Always treat entities used for extension as if they were facets: do not attach other entities or facets
to them, but to their central entity.

CONSIDER denormalizing the logical keys of referenced entities inside the facet to improve
performance.
Use Post-Actions to synchronize this information. Also consider adopting custom views to
optimize frequently-used queries.

CONSIDER using Property, Parameter or User Field entities in Master Data.

Entities that contain unpivoted properties should be used when you intend to add new properties
during runtime.

CONSIDER using Custom Views for accessing relational data in the Database. Reading Functions
remain the only viable technique to access non-relational data.

CONSIDER adopting Event Orchestration for complex use cases (where for example data
manipulation is required) and use Signal Rules for simple event-based use cases.

AVOID fragmenting too much your model: when you do not foresee an independent usage of
several small facets.
Try to group very granular functionalities that rely on just a few properties, particularly if you
expect them to work together.
Use Custom Views to group together the facets that are involved in the same business logics.

AVOID using too much Property, Parameter or User Field entities ("unpivoted properties"), in
particular in the Operational Domain.
Be aware that entities containing unpivoted properties are bad for performance and poorly
managed by User Interfaces.
Use them only to contain descriptive fields that are used in Reference or Master Data Domain.

Opcenter Execution Foundation 4.1 - Extensibility Guide 23

Extensibility in Opcenter EX FN at a glance

How to Customize a Specific Manufacturing Use Case

 For more information, see the Best Practices for Software Development section in the Opcenter Execution
Foundation Development and Configuration Guide.

3.2 How to Customize a Specific Manufacturing Use Case

Once you have extended basic Opcenter Execution Foundation functionalities with your custom behaviors, you can
organize them into well-structured containers and call them into play during the overall production process.
You can either use your commands directly or collect them into Task Types, which are basic activities that go
through a fixed state machine.
Then you can orchestrate Task Types inside Process Definitions to define specific execution criteria.

 Customization at this level requires using Opcenter Execution Foundation Project Studio, either for
implementing Business Logic or for developing specific Task Transitions.

The three Industrial Reference Models

We can single out three industries that typically apply different approaches in modeling Task Types and Business
Process Definitions:
• Complex Manufacturing is characterized by High Complexity (thousands of basic activities per finite product),
Low Volume (one finite product per day or less), High Variability (one to ten finite products based on the same
engineering).
• Very High Volume Manufacturing is characterized by Low to Medium Complexity (approximately ten basic
activities per finite product), Very High Volume (thousands of finite products per day), Low Variability (most of
the finite products based on the same engineering).
• Repetitive/One-Piece-Flow Manufacturing is characterized by Medium Complexity (tens to hundreds of activities
per finite product), High Volume (hundreds of finite products per day), Medium/Very High Variability (from
most of the finite products based on the same engineering in mass production to one product per engineering in
One-Piece-Flow production).

3.3 How to Customize your Solution

Once you have defined your custom functionalities, you can combine them to form Apps and UI Apps for creating
solutions.
Whereas Apps are industry-oriented collections of artifacts and UI Apps are customizable packages according to
User Roles, Solutions are targeted on a specific project.

Available Customization Options

Depending on your needs, by using Solution Studio you can choose to:
• Customize the UIs provided by the Foundation Apps. This can be achieved by using the Mashup Editor to
combine UI Components to form new UI Modules to be added to your UI application. This new UI application is
not so much a revamped layout from a graphical standpoint, but rather a new way of presenting runtime data,
establishing relationships between its various elements according to your needs.
• Create a custom UI application. In this case, you can create a brand new App and define optimized modules for
your clients.
In both cases, once you have customized your solution, you must deploy it properly (see How to Develop an App for
a Manufacturing Use Case of the Opcenter Execution Foundation Development and Configuration Guide).

24 Opcenter Execution Foundation 4.1 - Extensibility Guide

 Extensibility in Opcenter EX FN at a glance

How to Customize your Solution

3.3.1 Configuring Business Logic from Solution Studio

When the existing functionalities and User Interfaces meet most of your requirements, you can fine-tune them in
Solution Studio and in the custom Apps.
For example, you can:
• Toggle Pre-Checks for single Apps
• Toggle Post-Actions for single Apps.

Toggling Pre-Checks
In Solution Studio, you can enable or disable Pre-Checks, as well as change their execution order.
Pre-Check behavior can be set in Solution Studio by choosing either of the following behaviors: Stop at first fail or
Fail and proceed:
• If the Stop at first fail is set, the Pre-Check execution stops at the first Pre-Check failure and all the subsequent
Pre-Checks are stopped.
• If the Fail and proceed is set, all Pre-Checks will be executed anyway regardless of the result of the preceding
Pre-Checks.
In both cases, the command will be executed only after the success of all Pre-Checks.
For details, see Configuring Command Settings in the Opcenter Execution Foundation Development and
Configuration Guide.

Toggling Post-Actions
In Solution Studio, you can enable or disable Post-Actions, as well as change their execution order. The toggling in
Solution Studio is allowed only if you have defined them as Optional in Project Studio.
For details, see Configuring Command Settings in the Opcenter Execution Foundation Development and
Configuration Guide.

3.3.2 UI Development and Extension

When single User Interface modules do not fully satisfy your requirements, you can extend the User Interface in a
custom Extension App.
In order to create from scratch, create from a copy or extend Model-Driven User Interfaces, you can refer to section
Extending a Model-Driven UI Module in an Extension App of the Opcenter Execution Foundation Development and
Configuration Guide.
If you want to create Mashup Modules, you can refer to section Designing Mashup UI Modules of the Opcenter
Execution Foundation Development and Configuration Guide.

Opcenter Execution Foundation 4.1 - Extensibility Guide 25