NarrowBand IoT Wide Range of Opportunities en

Sigma Order Management
Version 2.0
Design Time Guide

Copyright © 1996-2015 Sigma Systems Canada Inc.
Sigma Systems Canada Inc., Toronto, ON, Canada
The Programs (which include both the software and documentation) contain information that is proprietary to
Sigma Systems Canada Inc. and its licensors; they are provided under a license agreement containing restrictions
on use and disclosure and are also protected by copyright and other intellectual and industrial property laws.
Except as may be expressly permitted in such license agreement, no part of the Programs may be reproduced or
transmitted in any form or by any means, electronic or mechanical, for any purpose. Reverse engineering,
disassembly, or decompilation of the Programs, except as expressly permitted by law, is prohibited.
The information contained in this document is subject to change without notice. If you find any problems in the
documentation, please report them to us in writing. This document is not warranted to be error-free.
Sigma product names are trademarks of Sigma Systems Canada Inc., and may be registered in certain
jurisdictions. Other names may be trademarks of their respective owners. A complete list of third-party software
and copyrights is included in the libraries of each binary distribution.
i
Contents
About this Guide ...............................................................................1
Audience .................................................................................................1
For More Information .............................................................................1
Fulfillment Designer Tasks .................................................................3
Obtaining Fulfillment Configurations from Sigma Catalog.......................3
Managing Domain Releases ....................................................................4
Selecting a Domain Release ....................................................................4
Creating a Domain Release .....................................................................5
Exporting a Domain Release ...................................................................6
Deploying a Domain Release ...................................................................6
Closing a Domain Release .......................................................................6
Creating and Managing Domain Entities .................................................6
Unpublished ........................................................................................6
Processes ............................................................................................7
Assessment Processes ............................................................................... 7
Fulfillment Processes............................................................................... 10
Fulfillment Subprocesses ......................................................................... 15
Systems............................................................................................. 17
Fulfillment Systems ................................................................................. 17
Workgroups....................................................................................... 21
Managing Configuration Changes ......................................................... 23
Validating a Release .......................................................................... 23
Publishing Domain Configurations .................................................... 23
Closing the Workspace .......................................................................... 24
Ensuring Consistent Configurations Across Fulfillment Applications ..... 24
Integration Specialist Tasks .............................................................25
Creating Technical Integrations ............................................................. 25
Source Control Integration Configurations ............................................ 25
Publishing Integration Configurations ................................................... 25
Sigma Order Management 2.0 Design Time Guide

© Sigma Systems | Company Confidential
ii
Configuration Manager Tasks .......................................................... 27
Resolving Configuration Conflicts ......................................................... 27
Configuration Conflicts ..................................................................... 27
Command Line Access....................................................................... 28
Resolving Publishing Conflicts .......................................................... 28
Resolving Deploy Conflicts ................................................................ 30
Resolving Rebase Conflicts ............................................................... 32
Design‐Time Modelling.................................................................... 35
Index ............................................................................................... 37

1
About this Guide
This guide explains the role of users (actors) responsible for configuring the Sigma Order
Management application (design-time).
Audience
This document is designed to give the following audiences a high-level understanding of the
capabilities of Sigma Order Management:
• Fulfillment Designers
• Integration Specialists
• Configuration Managers
• Anyone involved in design time modelling
For More Information
See the following product guides provided with your Sigma Order Management 2.0 product
distribution:
• Sigma Order Management 2.0 Release Notes
• Sigma Order Management 2.0 Product Overview
• Sigma Order Management 2.0 Installation Pre-requisites and Hardware Sizing Guide
• Sigma Order Management 2.0 Installation Guide
• Sigma Order Management 2.0 Domain Concepts Guide
• Sigma Order Management 2.0 Runtime Guide
• Sigma Order Management 2.0 REST API Guide
• Sigma Order Management 2.0 Developer Guide

2

3
Fulfillment Designer Tasks
The Fulfillment Designer is responsible for modelling all aspects of fulfillment for the various products,
services and resources being offered by the service provider. Fulfillment Designers require extensive
knowledge about the provider’s business, including an understanding of the capabilities of the various
systems in the BSS and OSS stack, how products and services are fulfilled, and how fallout is
handled.
The fulfillment designer may perform any of the following tasks:
• Obtaining Fulfillment Configurations from Sigma Catalog
• Managing Domain Releases
• Selecting a Domain Release
• Creating a Domain Release
• Exporting a Domain Release
• Deploying a Domain Release
• Closing a Domain Release
• Creating and Managing Domain Entities
• Managing Configuration Changes
• Closing the Workspace
• Ensuring Consistent Configurations Across Fulfillment Applications
Obtaining Fulfillment Configurations from Sigma Catalog
Fulfillment Designers work in Sigma Catalog to extend product, service and resource configurations
with fulfillment logic, such as technical attributes, defaults, inference rules, etc. This is easily done by
selecting Sigma Catalog from the application Launchpad at the top left of the menu bar. Fulfillment
extensions to the Sigma Catalog should only be made in consultation with a Product Manager.
Fulfillment Designers can obtain the latest fulfillment configurations from Sigma Catalog for use
during modeling in OM Designer as follows:
1 Launch Sigma Catalog.
2 Use the Sigma Catalog workbench to place any necessary change sets into the Sigma Order
Management test set. This is the test set that Sigma Order Management will use at runtime.
Change sets are entities updated either by the Fulfillment Designer or Product Manager and may
affect the fulfillment configuration.
3 Publish the test set from Sigma Catalog.
4 Using OM Designer, load the latest published Sigma Catalog test set into the workspace:
a. Copy the new or updated files to the productSpecifications directory.

4
b. Restart the OM node.

Note: The new version of Catalog must contain the information from the old one. Otherwise, in-
flight orders might be impacted and fail. Changing a characteristic from a single value to multiple
values or vice versa may cause OM to fail, as it involves different storage.
5 Reconcile the latest configuration with the existing OM configuration.
Managing Domain Releases
All release management functions are performed from the Releases screen. The Releases screen is
the first screen to appear after logging into OM Designer.
Design Time UI
Releases on which you are working are tagged with a wrench icon to the left of the release
name. This means you have previously opened the release and are working on changes to it in your
local environment. These changes cannot be seen by others until they are published to source
control.
Selecting a Domain Release
Each time a Fulfillment Designer logs into OM Designer, they are prompted to select a release to
work with. Selecting a release results in the creation of a workspace in the user's local environment.
The workspace represents a private area where the user can work independently from other users on
their team until their changes are ready to be published back to the source control repository.
Likewise, other users that select the same release on which to work will have independent copies of
the configuration in their own environments. These users are able to work independently from one
another, but must ultimately publish their changes back to the source control system.

5
To return to the Release Management page after you have selected a release, click the Releases link
on the top left side of the page next to the release name.
Warning: Do not open the same workspace across multiple browser instances or browser tabs at the
same time.
Creating a Domain Release
A new release can be created from an existing version (also referred to as a commit) that was created
by you or another user. You can take this action to formalize the changes committed to the source
control system. For example, you can create a release to provide to the QA team for testing.
To create a release:
1 Select the trophy icon on the right side of the release on which you would like to base the
new release.
This displays a list of all the commits that have been created for the release.
2 Select the version on which you wish to base the new release.
The Create Release dialog appears.
3 Provide a name and description for the new release.
The release appears on the main Releases page.

6
Exporting a Domain Release
Releases may need to be exported for a number of different reasons, including:
• Providing the release to someone without access to source control (e.g., the configuration needs
to be deployed to a runtime environment on a different network).
• To allow offline development when network access is unavailable.
To export a configuration:
1 Select the release by clicking the export icon (script icon ) on the right side of the screen.
A zip file containing the release configuration is created.
2 Distribute the file as necessary.
Deploying a Domain Release
Fulfillment Designers can deploy a release to a specific environment from the Releases page. This
function is used, for example, to build a QA or development environment.
To deploy a release:
1 Select the cloud icon to the right of the release you wish to deploy.
2 Select the environment to which to deploy the release.
Closing a Domain Release
Closing a release removes your ability to make changes to that release in your personal environment.
If you have made any changes to the release, you will lose the changes unless they have first been
committed to source control (see Publish Domain Configurations). A confirmation message appears
prior to performing the close.
Creating and Managing Domain Entities
Domain entities are business configurations that are typically deployed to multiple environments,
such as development, test, QA and ultimately production environments. Examples of domain
configurations include BPMN workflows, Fulfillment Systems, Processes and Tasks. Tabs across the
top of the screen allow you to navigate to the various entities within the release and make changes to
them in your private environment. Each tab is explained in the following subsections.
Unpublished
Displays a list of the configuration changes you have made in your personal environment, along with
the number of entities of each type you have changed. When you first select a release, no entities
appear on this screen as no changes have yet been made.

7
Processes
The Processes tab lists the fulfillment, assessment and subprocesses within the release, along with
the respective number of items of each type that you modified in your local environment.
Assessment Processes
Assessment processes are always the first type of workflow invoked when an order is received from a
submitting channel. Assessment processes perform specific actions on an order prior to initiating
fulfillment. For example, they perform commercial order validation, order decomposition, and/or
retrieval of the customer profile. To select the correct assessment processes for an order, an
assessment processes selector (which is a special type of business rule) must be configured.
To create an assessment plan:
1 Select the Processes tab.
2 Click the Assessment tab on the left side of the screen. A list of existing assessment processes
appears (if previously configured).
3 From the New Item dropdown on the top right of the screen, select Assessment Processes.
4 Assign a unique name to the assessment process.
5 Use the BPMN editor to model the assessment process. To do this:
a. Select a source element in the workflow, such as the start event

8
b. Click the entity you wish to add from the popup toolbar that appears (e.g., a gateway or
another activity). When creating a gateway, change the gateway type as needed by clicking
the toolbar icon from the popup. Supported types are inclusive and parallel.
Note: When connecting activities to a gateway, an expression must be added for inclusive
gateways (see below).
c. Type a name for the activity in line and then specify a Java class (Class Name) to execute for
the activity. Do this by clicking the edit icon on the lower right side of the activity.
If the activity is being connected to a gateway, then add a gateway expression by clicking the
edit icon (pencil on paper) that appears on the line. The New Gateway Sequence Flow dialog
appears.

9
d. Choose any of the following options:

• Is Default: Select this option if this is the path to be taken when no other gateway
conditions evaluate to true.
• Expression Builder: Construct an expression to determine if this path should be taken.
Add as many AND and OR conditions as required by clicking the + icon. For each
condition you can select the following options:
• Entity Name: Choose one of the following options:
• Customer: Use customer characteristics in the condition. These characteristics
are modelled within the Customer specification in Sigma Catalog and can be
modified as needed.
• Order: Use order header characteristics in the condition. These characteristics
are modelled within the Order specification in Sigma Catalog and can be
modified.

10
• Characteristic
• Value
6 Create an assessment process selector by clicking the Process Selector tab and adding new
rules. Choose any of the following options:
• Default Process: Select this option for this process if no other process conditions evaluate to
true. The current default plan name is shown.
• Add Condition: Construct an expression to determine if this process should be taken. Add as
many conditions and rules as needed. For each condition, select options by clicking within the
row. The Process Selection Rule dialog appears.
• Entity name: Choose any of the following options:

• Customer: Use customer characteristics in the condition. These characteristics are
modelled within the Customer specification in Sigma Catalog and can be modified as
needed.
• Order: Use order header characteristics in the condition. These characteristics are
modelled within the Order specification in Sigma Catalog and can be modified as needed.
• Characteristic
• Value
You can add more rows by clicking the + icon.
7 When the assessment process is complete, save it by clicking the save icon on the toolbar
located in the upper right side of the screen.
8 Click the Validate Process icon to ensure the assessment process is valid.
Fulfillment Processes
Fulfillment processes describe the high level sequence of actions (fulfillment steps) required to fulfill
the products, services and resources for orders. Fulfillment processes contain BPMN constructs,
including start events, end events, Sigma fulfillment subprocesses and Sigma gateways.
To model a fulfillment process:
2 Click the Fulfillment tab on the left side of the screen. A list of existing fulfillment processes
appear (if previously configured).

11
3 From the New Item dropdown on the top right of the screen, select Fulfillment Process.
4 Assign a unique name to the fulfillment process.

5 Use the BPMN editor to model the fulfillment process. To do this:
a. Select a source element in the workflow, such as start event.
b. Click the entity you wish to add from the popup toolbar that appears:
• Gateway: Create the gateway and then change the gateway type as needed by clicking
the wrench icon on the popup. Supported types are inclusive and parallel. Note:
When connecting activities to a gateway, an expression must be added for inclusive
gateways as described below.
• Subprocess: Select an existing fulfillment subprocess from the list by selecting the radio
button. Be sure to click the radio button to add the subprocess (clicking on the subprocess
name, takes you to the subprocess editor). The other option is to create a new
subprocess and provide a name for it. To create a new subprocess, see the Fulfillment
Subprocess section below.

12
If the fulfillment subprocess is being connected to a gateway then add a gateway

expression by clicking the edit icon that appears on the line.

The following options are available:

• Is Default: Select this option for this path if no other gateway conditions evaluate to
true.

13
• Catalog Interest: Click a condition (row) in the table to specify attributes of the
interest rule. Add as many rows as needed. Specify the following interest rule
attributes:
• Action: Select the action associated with the entity, such as any, add, update or
delete.
• Name: Select either the entity type (e.g., package, product or resource as
defined within Sigma Catalog) or specify an entity name. The tree on the right
side of the screen can be used to locate an entity.
• Within Entity: Optionally indicate a location to identify a specific entity instance.
The tree on the right side of the screen identities the entity instances.
• Include Children: Specify whether all children of the entity should be
accessible by future constructs along the path.
• Where: Specify additional conditions associated with the gateway path based
on characteristic values.
6 When configuration of the assessment process is complete, save it by clicking the save icon
on the toolbar located in the upper right side of the screen.
7 Click the Validate Process icon to ensure the fulfillment process is valid.
8 Create a fulfillment process selector by clicking the Process Selector tab and adding new rules:
• Default Process: Select this option for this process when no other process conditions
evaluate to true. The current default fulfillment process (if specified) is shown.
• Add Condition: Construct an expression to determine if this process should be taken. Add
conditions and rules to the expression as needed. Click within the row to specify Catalog
based rules. The Catalog Based Rules dialog appears:

14
The following options are available:

• Action: Select the action associated with the entity, such as any, add, update or delete.
• Name: Select either the entity type (e.g., package, product or resource as defined within
Sigma Catalog) or specify an entity name. For entity name, use the selector on the right
side of the screen to identify the location of the entity:
• Customer: Use customer characteristics in the condition. These characteristics are
modelled within the Customer specification in Sigma Catalog and can be modified as
needed.
• Order: Use order header characteristics in the condition. These characteristics are
modelled within the Order specification in Sigma Catalog and can be modified as
needed.
• Order item: Use order item characteristics in the condition. These characteristics are
modelled within the Order specification in Sigma Catalog and can be modified as
needed.
• Order Entity: Choose an entity (product, service, resource etc.) on which to base the
condition.
• Within Entity: Optionally indicate a location to identify a specific entity instance. The tree
on the right side of the screen identities the entity instances.
• Where: Specify additional conditions associated with the gateway path based on
characteristic values.
9 Save the configuration of the fulfillment process by clicking the save icon on the toolbar
located in the upper right side of the screen.

15
10 Click the Validate Process icon to ensure the fulfillment process is valid.
Fulfillment Subprocesses
A fulfillment subprocess is a special type of BPMNv2 call activity that encapsulates one or more
tasks. Each task in the subprocess flow communicates with a specific fulfillment system.
To create a fulfillment subprocess:
2 Click the Subprocess tab on the left side of the screen. A list of existing fulfillment subprocesses
appears (if previously configured).
3 From the New Item drop-down in the top right of the screen, select Fulfillment subprocess.
4 Assign a unique name to the subprocess.

5 Use the BPMN editor to model the subprocess. To do this:
a. Select a source element in the workflow, such as start event.
b. Click the entity you wish to add from the popup toolbar that appears.
• Gateway: Create the gateway, then change the gateway type as needed by clicking the
wrench icon on the popup. Supported types are inclusive and parallel. Note: When
connecting activities to a gateway, an expression must be added for inclusive gateways
as described below.
• Task: Create the task and assign a unique name for the task. Set the task type by clicking
the wrench icon from the popup. Supported types are manual task and automated task. 

16
Note: You can not save the configuration until you set the task type. 
Provide task attributes by clicking the edit icon .
• For manual tasks, specify the workgroup to perform the task and specify the correct
base reference to use for the task. These references are inherited from the
workgroup to which the task is now associated. The base reference defines the data
that will be visible to the fulfillment operator at this task.
• For an automated task, specify the fulfillment system to perform the task and
specify the correct base reference to use for the task. These references are inherited
from the fulfillment system to which the task is now associated. The base reference
defines the data that will be visible to the fulfillment system. 

To view the associated task behavior, save the task and click the small fulfillment
folder on the left side of the icon. 


Override the underlying base configurations associated with the activity by clicking
the edit icons as needed throughout the diagram. Provide confirmation when
prompted to proceed. You can only change the Send configurations by setting the
Trigger (see Fulfillment Systems) to a value of Order. Start conditions and error
handling configurations cannot be overridden. However, you can create a new
fulfillment task template any time.
• If the fulfillment subprocess is being connected to a gateway then add a gateway
expression by clicking the edit icon that appears on the line. The following options are
available:
• Is Default: Select this option for this path if no other gateway conditions evaluate to
true.
• Catalog Interest: Click a condition (row) in the table to specify attributes of the
interest rule. Add as many rows as needed. Specify the following interest rule
attributes:
delete.
• Name: Select either the entity type (e.g., package, product or resource as
defined within Sigma Catalog) or specify an entity name. For entity name use
the selector on the right side of the screen to identify the location of the entity.
• Within Entity: Optionally indicate a location to identify a specific entity instance.
The tree on the right side of the screen identities the entity instances.
• Include Children: Specify whether all children of the entity should be available
along the path.

17
• Where: Specify additional conditions associated with the gateway path based
on characteristic values.
6 When configuration of the fulfillment subprocess is complete, save it by selecting the save icon on
the toolbar located in the upper right side of the screen.
Systems
The Systems tab lists the fulfillment systems within the release, along with the number of fulfillment
systems you have modified in your local environment, if any.
Fulfillment Systems
Fulfillment system configurations describe attributes of the external systems with which Sigma Order
Management must interact to fulfill products, services and resources. Examples of fulfillment systems
include inventory, work force management, billing, provisioning, etc.
To create a fulfillment system:
1 Select the Systems tab.
2 Click the Fulfillment System tab on the left side of the screen. A list of existing fulfillment
subprocesses appears (if previously configured).
3 Select Fulfillment System from the New Item drop down in the upper right corner of the screen.
4 Type a name for the fulfillment system.

5 Fill the remainder of the fulfillment system configuration, including:
• Description: Type a description for the fulfillment system, such as “Mobile provisioning
system” or “Device inventory”.

18
• OM Internal Interaction: Describes details of the interaction with the fulfillment system,
including:
• Name: Specifies the configuration to be used in interacting with the OM engine.
• Component: Identifies a logical function associated with the clip queues that hold
fulfillment system requests.
• Queue: Specifies the name of the clip queue that holds the fulfillment system request.
• Actions: Specifies the actions that can be performed on the fulfillment system, including the
name of the operation and the Interaction Reference (the name of the specific fulfillment
interaction to be invoked as configured previously under OM Internal Interaction).
• Tasks: Allows the Fulfillment Designer to create task templates for the fulfillment system
interaction to hold generic configuration inherited by other fulfillment tasks during modeling.
Provide a name for the task template and then specify the following configuration:
• Trigger: Controls the level at which the task is allowed to proceed with fulfillment. For
example, if the level is set to Item, then each order item that was fully processed by all
previous activities in the BPMN flow is processed by the task. If the entry condition is set
to Order, then fulfillment processing only commences once all order items are fully
processed by all previous activities in the BPMN flow.
• Send: Controls the way in which the activity exchanges data with a fulfillment system. It is
enabled only when the trigger type is set to Order:
• If Item is selected, then each order item available for processing by the activity is
sent individually (as separate messages) to the fulfillment systems.
• If Sub Order is selected, then all fulfillment items available for processing by the
activity are sent to the fulfillment systems as a single message.
• Internal Operation: Select the name of the operation to perform on the fulfillment system
for this task.
• Suborder Definition: Click the Suborder Definition tab on the left side of the screen, then
select the + symbol to specify the rules that trigger execution of the activity. For example,
an inventory system may need to be informed about all resources, or a billing system may
need to know about all prices. Rules can also be created against specific entities in Sigma

19
Catalog. Create as many groups and rules as needed. For each rule click the row to
specify:
delete.
• Name: Select either the entity type (e.g., package, product or resource as defined
within Sigma Catalog) or specify an entity name. Use the order tree on the right side
of the screen to navigate to the name.
• Within Entity: Optionally indicate a location to identify a specific entity instance. The
tree on the right side of the screen displays all instance of the entity you specify.
• Include Children: Specify whether all children of the entity should be available along
the path.
• Error Handling: Click the + symbol to add error codes and associated error logic for the
operation on the fulfillment system. The Error Handling screen appears.

20
Select any of the following options:

• Default: If selected and there is an unrecognized error response from the fulfillment
system, then the Handling Type you specify is used to handle the error.
• Component Name: The name of the component returning the specified error.
• Error Code: The error code returned from the fulfillment system.
• Description: A description of the error code returned from the fulfillment system.
• Handling Type: Select the way in which the error is handled:
• Fallout Group prompts for the name of the fallout workgroup that handles this
error (manual fallout handling).
• Fulfillment subprocess prompts for the name of the fulfillment subprocess that
handles this error (automated fallout handling).
• Custom prompts for the name of the Java class that handles this error (custom
error handling).
• Details: Include a description on the details tab.

21
Workgroups
The Workgroups tab lists the workgroups within the release along with the number of workgroups you
modified in your local environment, if any.
Workgroups encapsulate the Fulfillment Operators responsible for addressing manual tasks. When
manual tasks are created, they are assigned to a workgroup to address at runtime.
To create a workgroup:
1 Click the New Item drop down on the upper right side of the screen and select Workgroup.
2 Provide a unique name for the workgroup, such as “Design Approvers” or “Port Assignment”.
3 Fill the remainder of the workgroup configuration, including:
• Manual Tasks: Allows the Fulfillment Designer to create task templates that hold generic
configuration inherited by fulfillment tasks during activity modeling. Provide a unique name for
the manual task template and specify the following configuration:
• Trigger: Controls the level at which the task is allowed to proceed with fulfillment. For
example, if the level is set to Item, then each order item that was fully processed by all
previous activities in the BPMN flow is processed by the task. If the entry condition is set
to Order, then fulfillment processing only commences once all order items are fully
processed by all previous activities in the BPMN flow.
• Send: Controls the way in which the activity exchanges data with a fulfillment system. It is
enabled only when the trigger type is set to Order:
• If Item is selected, then each order item available for processing by the activity is
sent individually (as separate messages) to the fulfillment systems.
• If Sub Order is selected, then all fulfillment items available for processing by the
activity are sent to the fulfillment systems as a single message. Create as many AND
and OR groups as needed.
• Internal Operation: Always set to manualTaskOperation.
• Suborder Definition: Click the Suborder Definition tab on the left side of the screen, then
select the + symbol to add conditions and specify the rules that trigger execution of the
activity. For example, an inventory system may need to be informed about all resources,

22
or a billing system may need to know about all prices. Rules can also be created against
specific entities in Sigma Catalog. Click each row to specify the following rule attributes:
delete.
• Name: Select either the entity type (e.g., package, product or resource as defined
within Sigma Catalog) or specify an entity name. Use the order tree on the right side
of the screen to navigate to the name.
• Within Entity: Optionally indicate a location to identify a specific entity instance. The
tree on the right side of the screen identifies all the entity instances.
• Include Children: Specify whether all children of the entity should be available along
the path.
characteristic values. Add as many rows as needed.
• Error Handling: Click the + symbol to add error codes and associated error logic for the
operation on the fulfillment system. Options are:
• Default: If selected and there is an unrecognized error response from the fulfillment
system, then the Handling Type and Fallout Workgroup Name you specify are used
to handle the error.
• Component Name: The name of the component returning the specified error.
• Error Code: The error code returned from the fulfillment system.
• Description: A description of the error code returned from the fulfillment system.
• Handling Type: Select the way in which the error is handled:
• Fallout Group prompts for the name of the fallout workgroup that handles this
error (manual fallout handling).
• Fulfillment subprocess prompts for the name of the fulfillment subprocess that
handles this error (automated fallout handling).
• Custom prompts for the name of the Java class that handles this error (custom
error handling).
• Details: Include a description on the details tab.
• User Groups: Defined in the main authentication system (such as OpenAM). This represents
a link between the groups created centrally in the main authentication system and workgroups
specific to addressing manual tasks within Sigma Order Management. When a user group ->
workgroup assignment is complete, the users associated with the user group can also be
associated with the workgroup and appear within Sigma Order Management. You can have
multiple user groups associated with a workgroup.
• Subtasks: Click the subtasks tab on the left side of the screen, then select the + symbol to
specify the rules that decide what data will be visible to the user for the manual task. Rules

23
are created against specific entities in Sigma Catalog. Create as many AND and OR groups
as needed. Click each row to specify the following rule attributes:
• Action: Select the action associated with the entity, such as any, add, update or delete.
• Name: Select either the entity type (e.g., package, product or resource as defined within
Sigma Catalog) or specify an entity name. Use the order tree on the right side of the
screen to navigate to the name.
• Within Entity: Optionally indicate a location to identify a specific entity instance. The tree
on the right side of the screen identifies all the entity instances.
• Include Children: Specify whether all children of the entity should be available along the
path.
Managing Configuration Changes
Validating a Release
Prior to committing or deploying releases, Fulfillment Designers should validate the changes they
made to the release by using the Validate function on the dropdown next to the release name (wrench
icon ).
Note: To validate a release, first select the release on which to work from the Release page.
Publishing Domain Configurations
When Fulfillment Managers are ready to distribute the configurations they have created to a wider
audience, they can use the Publish or Publish and Close functions.
These functions are available from the dropdown next to the release name (indicated by the wrench
icon). Users should always provide a comment on the Publish dialog box to indicate what was
changed in the configuration.
Other Fulfillment Designers may be working simultaneously on the same releases. As long as they
are each working on independent parts of the configuration, no conflicts will arise during publication
and the changes are automatically merged into the latest commit. If two or more Fulfillment Designers

24
have been working on identical parts of the configuration (for example, they both change the same
fulfillment system), a conflict arises at publication time and the user is notified. If this occurs, please
seek the assistance of a Configuration Manager who can manually resolve the conflict.
Consider performing a validation of the changes you have made to a release before distributing your
configuration to others on your team.
Closing the Workspace
The close function closes the workspace in which you are working, resulting in the loss of any
changes you have made to the release. This function is available from the dropdown next to the
release name (wrench icon).
Ensuring Consistent Configurations Across Fulfillment
Applications
Fulfillment Designers base the fulfillment configuration on a version of Sigma Catalog that has been
imported into Order Management Designer for use during modeling. When fulfillment domain
configurations are eventually published to a runtime environment, it is important to ensure that the
configuration works as expected with the version of the Catalog that has been deployed to the
runtime environment (Sigma Catalog Services). Order Management Designer does not publish the
version of Sigma Catalog that was used to create the domain configuration. Sigma Catalog
configurations are deployed separately from the Sigma Catalog UI.

25
Integration Specialist Tasks
The Integration Specialist is responsible for creating technical integrations between Sigma Order
Management and third-party fulfillment systems. When the integration is expected to be non-
technical, a fulfillment designer may elect to act in this role. However, when technical complexity is
involved, an Integration Specialist’s services are typically required.
The Integration Specialist may perform any of the following tasks:
• Creating Technical Integrations
• Source Control Integration Configurations
• Publishing Integration Configurations
Creating Technical Integrations
Fulfillment Designers may not have the necessary skills to create the underlying technical
configurations for communicating with fulfillment systems since this may require coding. To create
these integrations, see the Software Developers Guide (SDK) for details of the process.
Source Control Integration Configurations
Sigma Order Management Integration Specialist can use Eclipse to edit Java code. For Sigma Order
Management 2.0, the version in use is Kepler Service Release 2. There is a standard code formatter
configuration for the above version of Eclipse that includes preferences that can be imported by
Eclipse.
Eclipse requires the Maven plugin to build supporting libraries into Sigma Order Management. To
perform a Maven build, users will require access to an artifact repository. This repository must contain
Sigma maven artifacts, which include the packaged versions of all other Maven projects on which the
current project depends.
Repository management is achieved through a Git plugin for Eclipse (Eclipse update source: http://
download.eclipse.org/egit/updates).
To use a Maven project with a Git repository, the Maven plugin requires the m2e plugin called m2e-
git, available from the m2e Marketplace.
Publishing Integration Configurations
Integration configurations created by Integration Specialist are linked to the fulfillment systems that
are created by Fulfillment Designers. The operations available are configured as part of the action
configuration for a fulfillment system. See the Fulfillment Systems section in this document for more
information.

26

27
Configuration Manager Tasks
The Configuration Manager is responsible for deploying certified domain releases to production
environments. The Configuration Manager can perform manual resolution of configuration conflicts.
Resolving Configuration Conflicts
Updating configuration data in Sigma Order Management Designer involves multiple users, all editing
isolated copies of a common repository of data. When the common repository is updated by different
users from copies created at different times, there is the possibility of conflicting changes that result in
failed Designer publishes and deployments. When this occurs, the Designer UI simply reports that the
publish or deploy failed and an administrator is then required to access the common and workspace
repositories directly to diagnose and resolve the conflict. This topic describes how that process is
carried out.
Configuration Conflicts
Configuration conflicts may occur at two points in the OM Designer workflow: when publishing and
when deploying. Both instances are essentially the same issue with slightly different causes:
• Publishing conflict: In this scenario, David and Cathy are editing the configuration in the same
instance of OM Designer. OM Designer has a reference to its source repository, which contains
the master copy of the configuration from which users create isolated workspaces (copies), as
well as where users' changes are copied to when publishing.
• David logs into OM Designer, which internally creates an isolated copy of the source
configuration repository for that user.
• Cathy logs into OM Designer, creating an additional isolated copy of the source configuration
for that user.
• David changes the IPVPN fulfillment plan and saves it.
• Cathy also changes the IPVPN fulfillment plan and saves it.
• At this point, both users have different changes that each exist in their respective workspaces
(isolated copies of the source configuration). These changes are only visible to their
respective users.
• David publishes his workspace. The publish is successful.
• Cathy publishes her workspace. An error occurs.
The error in the last step is due to a configuration conflict between Cathy's workspace and the
source configuration. Both users created their workspaces from the same version of the source
repository, but David published first. This results in the source repository being updated with
David's changes. Since Cathy's workspace was created before David's changes were published,
it does not contain those changes. Therefore, when Cathy publishes, her workspaces contain
changes to an out of date version of the source. This is usually not a problem since Git can
reconcile changes made to separate files, but since Cathy's changes were also made to the same
object (IPVPN), this is considered a conflict and the publish is not allowed.

28
• Deployment conflict: In this scenario, David and Cathy are editing configurations in separate
instances of OM Designer. Each instance of OM Designer references a separate source
repository. Both instances of OM Designer contain references to a third repository, referred to as
the target, which also contains a configuration.
• David logs into his instance of OM Designer, changes the IPVPN fulfillment plan on the MAIN
release, saves and publishes. The publish is successful.
• Cathy logs into her instance of OM Designer, changes the IPVPN fulfillment plan on the MAIN
release, saves and publishes. The publish is successful since this is not the same OM
Designer instance and source. There is no conflict at this point.
• David deploys the MAIN release to the target repository. A deploy copies one Order
Management configuration release from one repository (in this case, David's OM Designer
source) to another (in this case, the target). The deployment is successful.
• Cathy deploys the MAIN release to the target repository. An error occurs.
The error in the previous step is similar to a publish conflict, but involves different steps in the
workflow for copying changes. Both users successfully published their changes to their respective
source repositories, but Cathy's source modified the same entity (IPVPN) as David’s. When she
tried to deploy, the same scenario as above occurred, except David’s and Cathy's sources took
the place of their workspaces and the target repository took the place of the common source.
Command Line Access
You must reconcile repositories if they were copied from a common source at some point in their
histories and have conflicting changes. This involves deciding which version of files to keep, which to
drop, or if a merge is possible.
Resolving conflicts requires the Git command line utility and direct file system access to the source,
target and workspace repositories. In the example below, the following is used:
[root@aqcentos conflict_copy]# git ‐‐version
git version 1.7.1
Resolving Publishing Conflicts
This example directly extends the above publish conflict scenario, where Cathy encountered an error
when attempting to publish after David had published his change. These steps describe how to use
the Git command line utility to resolve the conflicts between Cathy's workspace and its associated
source, the OM Designer repository.
1 Log out of OM Designer.
2 As an administrator, start a command prompt on the OM server.
3 Track the log file output using a command inside the OM runtime directory filtered by a specific
pattern:
tail ‐f nohup.log | grep ‐i 'using workspace' | grep ‐i 'cathy'
4 From a web browser, log into OM Designer as Cathy and select the workspace that failed to
publish.
5 From the command prompt, look for output that resembles the format:

29
2014‐11‐11 00:20:24,844 [info] CfgUtils: using workspace: Cathy Jones|MAIN; rel: MAIN; src:
/mnt/data/om‐web‐0.0.1‐SNAPSHOT/workinggit/workspaces/4
The src field represents the file system location of the desired workspace.
6 Copy the workspace directory to a separate location so that it can be safely worked with:
cp –r /mnt/data/om‐web‐0.0.1‐SNAPSHOT/workinggit/workspaces/4 ~/conflict_copy
This copy is hereafter referred to as CONFLICT_REPO_DIR.
7 From a command prompt on the OM server, set the current directory to CONFLICT_REPO_DIR:
cd ~/conflict_copy
The pending changes can be seen with the 'status' command:
[root@aqcentos conflict_copy]# git ‐‐status
# On your branch master
# Your branch is behind ‘origin/master’ by 1 commit, and can be fast‐forwarded.
#
# Changes to be committed:
# (use “git reset HEAD <file>...” to unstage)
#
# Modified: FULFILLMENT_PLANS/IPVN.json
#
The pending changes show the IPVPN fulfillment plan was modified and is pending.
8 Commit the pending changes to the local repository. Enter a message; this is equivalent to the
publish message entered in OM Designer.
git add . ‐‐all
git commit ‐m 'This is my publish message.'
At this point, the status command should return a clear status:
[root@aqcentos conflict_copy]# git status
# On branch master
# Your branch and ‘origin/master’ have diverged,
# and have 1 and 1 different commit(s) each, respectively.
#
nothing to commit (working directory clean)
Note that while there are no more pending files, Git indicates the local and origin branches have
diverged. This means the commit made locally is not present on the target and the target has a
commit that does not exist on the local copy. The goal of subsequent steps is to insert the commit
on the target into the sequence of commits in the local copy, creating a change path that includes
both.
9 Run the following command to attempt to reconcile the diverging changes:
git rebase FETCH_HEAD
This command results in an error due to the conflicting changes. This is the same conflict that
occurred when the publish was attempted in OM:
[root@aqcentos conflict_copy]# git rebase FETCH_HEAD
First, rewinding head to replay your work on top of it...
Applying: This is my publish message.
Using index info to reconstruct a base tree...
Falling back to patching base and 3‐way merge...
Auto‐merging FULFILLMENT_PLANS/IPVPN.json
CONFLICT (content): Merge conflicts in FULFILLMENT_PLANS/IPVPN.json
Failed to merge in the changes.
Patch failed at 0001 This is my publish message.

30
When you have resolved this problem run “git rebase ‐‐continue”.
If you would prefer to skip this patch, instead run “git rebase ‐‐skip”.
To restore the original branch and stop rebasing run “git rebase ‐‐abort”.
10 Follow the steps described in Resolving Rebase Conflicts to complete the rebase operation.
The previously conflicting repository is now reconciled with its target into a single change history.
Copy the changes to the target:
git push
11 In OM Designer, close all workspaces for Cathy. CONFLICT_REPO_DIR can now be discarded.
Resolving Deploy Conflicts
This example directly extends the above deployment conflict scenario, where Cathy encountered an
error when attempting to deploy a release to a target environment after David executed a deploy. The
following steps describe how to get a working copy of the conflicting Designer source repository for
use in later sections.
1 Access the configuration for the OM Designer source repository in the environment configuration
utility (http://<server>:<port>/envcfg), in the Domains section.
This is a relative path to the OM home directory on the file system, or an SSH URL, depending on
how the repository is accessed. If accessed through SSH, the same connection credentials must
be usable by the Git command line utility (for example, a private key registered in an SSH agent).
2 In a separate location (such as the home directory), clone the source repository using the
absolute version of the path as seen above at the command prompt:
git clone /mnt/data/omp‐cfg‐demo.git ~/conflict_copy
3 In the environment configuration utility, access the target repository in the Domains section. This
is the destination selected when the conflicting deploy was attempted.

31
This is a path relative to the OM home directory or an SSH URL.

4 From the command prompt, change the current directory to where the conflicting source
repository was cloned:
cd ~/conflict_copy
5 Add a new remote reference named target_repo that points to the target repository:
git remote add target_repo /mnt/data/target_repos/omp‐cfg‐demo.git/
6 Retrieve data from the target:
git fetch target_repo
The above command retrieves the Git branches and pointers contained in the target repository.
The command output indicates which new references have been added to the local repository.
7 Run the branch command to display the list of all available references:
[root@aqcentos conflict_copy]# git fetch target_repo
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 2), reused 2 (delta 0)
Unpacking objects: 100% (4/4), done.
From /mnt/shared/omp_repos/omp/omp‐cfg‐demo
* [new branch] _CFGMGR_RLS_engine_test_1.0 ‐> target_repo/_CFGMGR_RLS_engine_test_1.0
* [new branch] master ‐> target_repo/master
[root@aqcentos conflict_copy]# git branch ‐a
* master
remotes/origin/HEAD ‐> origin/master
remotes/origin/_CFGMGR_RLS_engine_test_1.0
remotes/origin/master
remotes/target_repo/_CFGMGR_RLS_engine_test_1.0
remotes/target_repo/master
Every OM Designer release is represented in the Git repository by a branch with the
_CFGMGR_RLS_ name prefix. The only exception is the MAIN release, whose branch is always
named master. In the above example, both the current repository (whose branches start with
remotes/origin/) and the target repository (whose branches start with remotes/target_repo/)
contain the MAIN release and a release named “engine_test_1.0”. Special characters in these
branch names are URL encoded to prevent any potential naming issues. This ensures that
branch names match those output by the branch command when working with the Git command
line utility.
Since the deploy conflict scenario described above only involves changes to the MAIN release,
the conflict occurs when attempting to reconcile this repository's master branch with that of the
target.
8 Execute the following command to attempt this reconciliation:
git rebase remotes/target_repo/master
This command results in an error due to the conflicting changes. This is the same conflict that
occurred when the deploy was attempted in OM:
[root@aqcentos conflict_copy]# git rebase remotes/target_repo/master
First, rewinding head to replay your work on top of it...
Applying: Cathy Jones Wed Nov 12 11:38:33 EST 2014
Using index info to reconstruct a base tree...
<stdin>:20: training whitespace.
{

32
“description” : “IPVPN fulfillment plan 2”,
“name” : “IPVPN”
“bpmnId” : “IPVPN”
“planSelector” : { },
warning: squelched 3 whitespace errors
warning: 8 lines add whitespace errors.
Falling back to patching base and 3‐way merge...
Auto‐merging FULFILLMENT_PLANS/IPVPN.json
CONFLICT (content): Merge conflicts in FULFILLMENT_PLANS/IPVPN.json
Failed to merge in the changes.
Patch failed at 0001 Cathy Jones Wed Nov 12 11:38:33 EST 2014
9 Follow the steps described in Resolving Rebase Conflicts to complete the rebase operation.
The previously conflicting branch is now reconciled with the corresponding branch in the target
repository to create a single change history.
10 Copy the branch to the target:
git push target_repo master:master
The above command would be used for deploying the MAIN release. If the user attempted to
push a release named “engine_test_1.0” in OM Designer, the last portion of the command would
be: '_CFGMGR_RLS_engine_test_1.0:_CFGMGR_RLS_engine_test_1.0'.
Resolving Rebase Conflicts
The instructions contained in this section assume that a rebase has been attempted on the Git
repository in the current directory and encountered errors, requiring user input before proceeding.
The examples used are from the above outlined publish conflict and deploy conflict scenarios. For
multiple conflicts, repeat these instructions for every conflict until the rebase (continue or skip) reports
there are no more conflicts.
1 View the status command. It indicates there are unmerged paths and provides a list of offending
files:
# Not currently on any branch
# Unmerged paths:
# (use “git reset HEAD <file>...” to unstage)
# (use “git add/rm <file>...” as appropriate to mark resolution)
#
# both modified: ORCHESTRATOION_PLANS/IPVPN.json
#
no changes added to commit (use “git add” and/or “git commit ‐a”)
2 Decide what to do with each conflicting change:
• Use the target version: To keep David's change to the IPVPN fulfillment plan and discard
Cathy's, execute these commands:
git checkout ‐‐ours FULFILLMENT_PLANS/IPVPN.json
git add FULFILLMENT_PLANS/IPVPN.json
• Use the local version: To overwrite David's change with Cathy's, execute these commands:

33
git checkout ‐‐theirs FULFILLMENT_PLANS/IPVPN.json
• Create a custom version: Manually alter the contents of the conflicting files, possibly taking
Cathy's, David's, or both, to create an entirely new version of the file. You can also make no
changes. When the last command was executed (rebase), Git annotated all conflicting files
with the different contents of the conflicting sections. Using these annotations, which come in
a few forms, you can selectively incorporate the different changes (see the Git merge
documentation for more detailed explanations of the '<<<<<<<', '=======', and '>>>>>>>'
tags). The FULFILLMENT_PLANS/IPVPN.json file can be modified directly in any appropriate
editor to facilitate this.
Execute the following command when editing is completed:
At this point, each conflicting change has been resolved via the add command.
3 Continue the rebase operation that initially encountered an error:
git rebase ‐‐continue
The previous command may fail if the conflict is resolved in a way that results in no changes to
the file in the current repository. In that case, Git gives the following error:
[root@aqcentos clone_test]# git rebase ‐‐continue
Applying: Cathy Jones Wed Nov 12 11:38:33 EST 2014
No changes ‐ did you forget to use ‘git add’?
Execute this command:
git rebase ‐‐skip

34

35
Design‐Time Modelling
Existing process flows can be directly re-used, extended or copied to a new flow to encapsulate the
desired fulfillment behavior.
BPMN workflows (fulfillment plan specifications) are modeled at design-time and managed through
Sigma OM Designer's Graphical User Interface (UI). Any BPMNv2 compliant modelling tool can also
be used to create and maintain workflows. Workflows created using third party tools can be easily
imported into OM designer for further fulfillment configuration enrichment. At runtime, orders that
were commercially validated are technically enriched during decomposition via Sigma Catalog
services.
Decomposition steps include enriching the order with attribute values needed to fulfill the order,
copying attribute values from one location to other locations on the order, and enriching the order with
additional products, services or resources necessary to fulfill the order. For example, the selection of
a particular commercial product means that a specific type of equipment is needed to fulfill the
product.
As part of this process, a fulfillment plan is dynamically generated from the fulfillment plan
specification. This is done by discarding any unnecessary activities in the fulfillment plan specification
to ensure that only necessary fulfillment interactions are performed for each order instance. The
fulfillment plan specifies the sequence of fulfillment activities required and fulfillment systems with
which Sigma Order Management must interact to fulfill the products and services on the order
instance.

36

37
Index
A workgroups 21
actors manual task templates 21
configuration manager 27
fulfillment designer 3
integration specialist 25
C
configuration conflict
27
command line access 28
deployment 28
manual resolution 27
resolving deploy conflicts 30
resolving publishing conflicts 28
resolving rebase conflicts 32
D
domain
create and manage entities 6
domain entities
assessment processes 7
fulfillment processes 10
fulfillment sub-processes 15
systems 17
actions 18
details 20, 22
error handling 19, 22
internal interaction 18
internal operation 18, 21
send 18, 21
suborder definition 18, 21
subtasks 22
tasks 18
user groups 22
trigger 18, 21
unpublished 6

38


NarrowBand IoT Wide Range of Opportunities en

Uploaded by

Copyright:

Available Formats

NarrowBand IoT Wide Range of Opportunities en

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NarrowBand IoT Wide Range of Opportunities en

Uploaded by

Copyright:

Available Formats

Sigma Order Management

Design Time Guide

Sigma Systems Canada Inc., Toronto, ON, Canada

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

b. Restart the OM node.

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

2 Select the environment to which to deploy the release.

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

d. Choose any of the following options:

Sigma Order Management 2.0 Design Time Guide

• Entity name: Choose any of the following options:

Sigma Order Management 2.0 Design Time Guide

4 Assign a unique name to the fulfillment process.

Sigma Order Management 2.0 Design Time Guide

If the fulfillment subprocess is being connected to a gateway then add a gateway

The following options are available:

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

The following options are available:

Sigma Order Management 2.0 Design Time Guide

4 Assign a unique name to the subprocess.

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

4 Type a name for the fulfillment system.

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

Select any of the following options:

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

This is a path relative to the OM home directory or an SSH URL.

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

Sigma Order Management 2.0 Design Time Guide

You might also like