Order Orchestration EG v1.0
Order Orchestration EG v1.0
Orchestration
Exercise Guide
Version 1.0
1
Industries Order Management
Orchestration Exercise Guide
TABLE OF CONTENTS
Preface 6
Overview 6
What You Will Learn 6
Prerequisites 6
Orchestration Overview 7
Industries Order Management Orchestration 7
What is Order Orchestration? 7
Exercise 6-14: More Robust Order Orchestration and Staggered Retry policies Challenge
Task 1: Refresh several orchestration concepts (optional) 260
Task 2: Review the finished orchestration plan 261
Task 3: Build out the orchestration plan 262
Task 4: Test the new orchestration plan 263
Task 5: Configure a staggered integration retry policy 267
Preface
These training exercises are based on the Spring '22 release of Salesforce Industries
Communications, Media, and Energy & Utilities Clouds. For additional information about
the topics covered in this module, see the documentation available in the Success
Community at https://success.vlocity.com.
Overview
This module covers fundamental features and functionality of the Salesforce Industries
Order Management (IOM) application as it pertains to orchestration. This module will show
you how to design order orchestration plans, manual tasks, manual queues, and callouts to
external systems.
This is a hands-on module with practical lab exercises. The lab exercises are designed to be
used with the provided training playground.
Prerequisites
The prerequisites for this module include a solid understanding of basic Salesforce concepts
and functionality. You should also have a good understanding of the principles of order
management and a working knowledge of the telecommunications, media, or energy and
utilities industry business objectives.
Orchestration Overview
Industries Order Management Orchestration
Order Management offers comprehensive functionality across two primary areas:
● Order Decomposition
● Order Orchestration and (the focus of this exercise guide)
After an order has been successfully decomposed, sub-orders are then fulfilled using an
orchestration plan. The plan takes into account any dependencies that may exist between
orchestration items in various flows. The orchestration execution engine evaluates the
orchestration plan based upon pre-defined rules. It coordinates, sequences, and monitors
all interactions with external fulfillment systems to ensure that they are ultimately
successful.
Goal
● Group order processing tasks into orchestration plan definitions
● Define order processing tasks as orchestration item definitions
● Identify important stages of order processing using orchestration milestones
● Trigger order processing for specific products on an order using orchestration
scenarios
Tasks
1. Create an end-to-end master orchestration plan definition
2. Create orchestration item milestone definitions for the end-to-end master
orchestration plan
3. Create an orchestration scenario for the DSL Service product
Time: 15 mins
ALERT:
If you’ve just received your training playground, add your email address to the
system administrator profile to ensure you receive all system notifications. In
the upper-right, click on the Avatar and select Settings. Enter your email
address in the Email field on the Personal Information page and click Save.
Once an order has been successfully decomposed, the process of communicating with
external systems to fulfill an order can begin. Order Management controls the interactions
with these external systems through order orchestration. Orchestration processes are
generated dynamically, sequenced, and monitored according to each order’s context and
the specifications of each orchestration plan definition.
Orchestration plan definitions group order processing tasks for the fulfillment requests that
were created by the decomposition process. Each orchestration plan definition forms a
single swimlane in the orchestration plan, which is the run-time instance of the
orchestration plan definition.
Orchestration plan definitions are very flexible and can group processing tasks using a
variety of different organizing principles.
BEST PRACTICE:
Salesforce Industries recommends the guidelines listed below when designing
orchestration plan definitions.
● Create a main end-to-end plan to sequence the major milestones of all orders, such
as the start of the order and the completion of the order.
● Create separate orchestration plan definitions for each macro logical function, e.g.,
provisioning, logistics, inventory, or billing.
● Simplicity should be the goal, avoiding loops unless absolutely required.
● Creating assets should occur as an Auto Task as the final orchestration item before
the Complete Order milestone.
NOTE:
Orchestration plan definitions are reusable components that can be
associated with multiple products.
1. In the Lightning tab navigation bar, click Orchestration Plan Definitions. (If you
don’t see it, click More to expand the overflow dropdown menu.)
2. Click New.
3. In the New Orchestration Plan Definition dialog, enter the following information.
Show Order 1
The Show Order field allows you to specify the order that the orchestration plan’s swimlane
will display at run-time on the orchestration plan page. Assigning a value of 1 will guarantee
it displays at the top of the page.
The Scope field on an orchestration plan definition defines the default scope for the
orchestration items that are contained by the plan if the item does not have a scope
defined.
NOTE:
Orchestration scopes allow you to control how the orchestration execution
engine resolves orchestration dependencies among orchestration items at
run-time.
4. Click Save.
The next step is to create orchestration item definitions for Start Order and Complete Order
milestones.
There are five different types of orchestration items, each with different actions that are
triggered once the orchestration item reaches the Ready state.
Orchestration item definitions can include conditions that evaluate attributes or fields on
the product or order entity and also dependencies that are used to sequence the task
within its orchestration plan definition or among orchestration items from other
orchestration plan definitions. Orchestration items reach a Ready state and are executed
when all of their conditions and dependencies have been met. Orchestration Item
Definitions, when easily understood in context, are often referred to simply as “tasks”.
BEST PRACTICE:
Salesforce Industries recommends creating all orchestration plan definitions
and orchestration item definitions first and then specifying dependencies
between them.
3. In the New Orchestration Item Definition dialog, enter the following information.
Scope Global
NOTE:
Your training playground shows additional fields including: Point of No Return,
Rollback Plan Definition, and Rollback Group. Please ignore these fields for
now. They are used in future labs on order cancellation. (Leave the default
blank values.)
6. In the New Orchestration Item Definition dialog, enter the following information.
Scope Global
7. Click Save.
3. Click Save.
Now that the orchestration scenario has been defined, the E2E Master Plan can be
executed and reviewed, which you will do in the next exercise.
Goal
● Generate order processing tasks at run-time as an orchestration plan
Tasks
1. Generate an orchestration plan using the E2E Master Plan orchestration plan
definition
Time: 15 mins
NOTE:
This exercise requires the completion of an earlier decomposition exercise
(Creating Multi-level Decomposition Relationships. It also builds on the
previous exercise. (Getting Started with Order Orchestration.))
2. Click New.
4. Click Save.
5. Select Configure Order from the Power Launcher. This will launch the cart.
6. In the PRODUCTS panel, find the DSL Service product, and click Add to Cart. Recall
that DSL Service is the product that is tied to the Orchestration Scenario, which
decides if an orchestration plan is generated and executed or not.
7. In the red notification message, click the Take Me There icon to invoke the
configuration window.
9. Click Close.
10. In the cart header, click Decompose Order. The decomposition results should look
familiar, based on an earlier multi-level decomposition exercise. (You can click the
link icon for the source DSL Service, and the link icon for the destination VDSL2 CFS
fulfillment request to highlight their respective decompositions.)
11. In the Order Decomposition page, click the View Orchestration Plan button to
begin order orchestration execution.
● The current status of the orchestration item can be seen at a glance by the
color-coding. Since these are orchestration milestones, they all are colored
green to indicate that the orchestration item status is Completed.
● You can increase or decrease the sizing of the orchestration plan display using
your mouse's scroll wheel feature (or equivalent).
● You can reposition the plan within the display window with your mouse’s pan
feature. (For example, click and hold in the plan’s display window and
position the index finger up/down/left/right as desired.)
NOTE:
This exercise focuses exclusively on the E2E Master Plan swimlane. Any
additional swimlanes are not part of this exercise and can be ignored.
13. Hover over any orchestration item and review the item details on the pop-up.
NOTE:
The Orchestration Item Details pop-up window uses Classic Cards-based
layouts, and the base XOM card layouts must be installed as a post-install step
after installing the Salesforce Industries Communications, Media, and Energy
application package. These cards can be configured to display additional
information per your business requirements. The start/stop dates are not used
in this exercise.
14. In the Start Order process box, right-click and select View Record.
Notice in the Orchestration Item Details, you can see the dynamically generated
Orchestration Plan instance and the current State of the orchestration item. You can also
see the Orchestration Queue that this item was assigned to for processing.
16. In the Order Item section, click the Order Item link.
17. Review the Order Product Detail page, which allows you to see what product (and,
thus, which orchestration scenario) created this orchestration item. This is very
helpful information if debugging efforts are required.
18. Click your browser’s back button to return to the previous page.
19. In the Order Item section, click the Order/Fulfilment Request link.
20. Notice that this link allows you to see the order (or fulfillment request) that was
processed by this orchestration item.
By generating your first orchestration plan, behind the scenes, based on design time
configuration the orchestration execution engine created orchestration item instances
dependencies as well as a variety of other records. (Dependencies are covered in an
upcoming exercise.) The complexity of this web of records becomes crucial when you need
to make substantial changes to the orchestration definitions.
Goal
● Define order processing tasks that require user input as manual tasks
● Create manual queues to organize manual tasks
● Configure and test auto-assignment of users to manual tasks
Tasks
1. Create a Credit Check manual queue
2. Create a Credit Check manual task
3. Test the new manual task
4. Configure Auto Assignment of Salesforce Users to Manual Tasks
5. Test the Auto Assignment of User to Manual Tasks
Time: 30 mins
A manual task is an orchestration item that is used when user input is needed at a particular
place in the fulfillment flow, for example, manager approval or manual enrichment of data
onto an order. Each manual task can be created with a custom task execution URL, which
can call an OmniScript or other interface to execute the manual task. When the manual task
is marked complete, the orchestration execution engine automatically moves to the
subsequent tasks.
Unlike orchestration queues, which are installed as part of the installed package,
administrators create manual queues, and once a task is placed in a queue by the
orchestration execution engine, users can access and process each task individually.
NOTE:
This exercise requires the completion of an earlier decomposition exercise
(Creating Multi-level Decomposition Relationships).
2. Click New.
5. Click Save.
Now that the manual queue is created, you can create a manual task that uses the queue.
In this example, you will use a Credit Check OmniScript to assist the user in completing the
task.
NOTE:
The Credit Check OmniScript used in this exercise has been prebuilt into your
training playground.
2. In the OmniScripts list, expand the VU/Credit Check OmniScript, and click Credit
Check.
3. Review the structure of the OmniScript. Pay particular attention to the Perform
Credit Check, and the Returned Credit Information steps, as you will see them later
in this exercise. Click through several components of these sections, using the
PREVIEW tab to see what the script execution will look like.
4. At the top of the page, click the How to launch activated script button.
5. Change the prebuilt page dropdown menu to Universal Page with Header/Sidebar.
6. In the first URL field, delete the domain to create a relative URL that begins with
/apex.
8. Click Ok.
14. In the New Orchestration Item Definition: Manual Task dialog, enter the following
information.
Scope Global
ALERT:
Ensure that the Custom Task Execution URL box has a relative URL that begins
with /apex/ or your OmniScript will not launch.
Please ignore the amend and rollback related fields that are shown. They are not used in
this exercise.
2. Click on the order number of the E2E Master Plan Test Order that you created
earlier.
3. Click Clone (either a button or a selection in the dropdown action menu in the
upper right).
4. Change the Order Name to E2E Master Plan Test Order #2.
5. Update the Status field to “Draft” and then click Save. (An order with Activated
status cannot be cloned then saved, hence the change to Draft before saving.)
7. In the PRODUCTS panel, find DSL Service and click Add to Cart.
8. In the red notification message, click the Take Me There icon to invoke the
configuration window.
11. In the cart header, click the Decompose Order button. The decomposition page
should look familiar.
14. Notice the new Credit Check manual task is color-coded in blue to indicate that the
task is in the Ready state. (Don’t worry if your tasks are displayed in a different order.)
15. Right-click the Credit Check process box and select the View Record option.
TIP:
Notice there are two manual queue operations in the drop-down menu:
Complete and Retry. Although you will not use them now, it's handy to know
they are there. You also have the option to launch the task’s OmniScript.
16. In the Orchestration Item Definition section under Manual Queue, click Credit
Check. This link takes you directly to the Credit Check manual queue.
17. In the Items In The Queue list, click the checkbox for the Credit Check entry and
then click the Pick up action link. The Credit Check OmniScript launches.
e. Click Complete.
19. You are returned to the Credit Check Orchestration Item, and the State should be
marked as Completed.
Also notice in the dropdown menu in the upper right, you can mark the item as Completed
by clicking the Complete Item button, or you can click Retry Item.
20. Click the link below Orchestration Plan, to view the updated plan. The Orchestration
Plan’s State is marked Completed and all three tasks are painted green (Start Order,
Credit Check, Complete Order).
1. Navigate to Setup, expand Users and click on Users > View All Users. Notice several
Salesforce users have been set up for you in the training playground. You will use
Allie Arbuckle, Bobby Brown and Charlie Chapman later in this task.
NOTE:
The Username is a required Salesforce field and must be globally unique. Your
Username will differ from what is shown above.
2. Return to Order Management and click Manual Queues > Credit Check.
3. Edit the Queue Type field. Select Round Robin from the dropdown menu. Click
Save.
ALERT:
If the Queue Type is left null (blank), auto assignment will not take place.
4. Scroll down and expand the User Membership section. This is where you add
Salesforce Users as members to specific Manual Queues.
5. Click the Add Member button. Check the box for Allie, Bobby and Charlie. Scroll
back up in the member names modal window and click Save.
Although you should not need to remove users from the queue membership for this lab, it
can be done using the Remove Member button or by switching to the Related tab, then
selecting Delete from the dropdown menu for the appropriate user name.
2. Expand the Items In The Queue section. Most likely there are no existing entries. If
there are entries, that is fine though. (Notice that the Assigned To User column is
blank, however.) Now you will create several orders and decompose them.
4. Click on the order number of the E2E Master Plan Test Order that you created
earlier.
5. Click Clone (either a button or a selection in the dropdown action menu in the
upper right).
6. Change the Order Name to E2E Master Plan Auto Assign in Manual
Queue “n”.
NOTE:
For “n” above, with each order you create, use 1, 2, 3, 4 at the end of each
order name for easy reference later.
7. Update the Status field to “Draft” and then click Save. (If your order’s status is
already “Draft” then you can skip this step. Activated orders cannot be saved.)
9. In the PRODUCTS panel, find DSL Service and click Add to Cart.
10. In the red notification message, click the Take Me There icon to invoke the
configuration window.
14. Click the View Orchestration Plan button (optional). Notice both milestone tasks in
the E2E Master Plan swimlane have completed, but the Credit Check manual task is
in a Ready state.
15. Return to the browser tab with the Credit Check Manual Queue. Refresh your
browser. You should have an entry for the Credit Check Manual Task in the queue,
auto assigned to a Salesforce user.
16. Repeat the steps above so that three more new orders are created for the same
product. Refresh your browser tab for the Credit Check Manual Queue each time
the new order is decomposed (and orchestration started). A new entry should be in
the queue and auto assigned each time. After four orders are entered, the queue
should look similar to the following.
Notice that after the three users within the queue membership are assigned a Manual Task,
the first member gets another assignment. (Allie Arbuckle in our example.) That is due to
the queue type, which uses a round-robin algorithm for assignment. If additional orders
were placed without any entries being completed, Bobby Brown would be assigned next,
then Charlie Chapman, and so on. (Rinse/repeat as they say. Voila!)
Goal
● Define order processing tasks that will be automatically executed as auto tasks
● Utilize advanced business logic and processing using item implementations
● Create assets using the Assetization item implementation
Tasks
1. Review the Assetizer item implementation
2. Create a Create Assets auto task
3. Test the new auto task
Time: 15 mins
NOTE:
This exercise requires the completion of an earlier decomposition exercise
(Creating Multi-level Decomposition Relationships).
1. In the Lightning search dialog, enter assetize, and click the Assetize item
implementation.
NOTE:
If search does not yield any results, you may need to expand the More
dropdown and click Item Implementations.
5. Click Next.
6. In the New Orchestration Item Definition: Auto Task dialog, enter the following
information.
Scope Global
7. Click Save.
NOTE:
Please ignore the unused Amend and Rollback related fields. They are used
later on and are not needed or required for this exercise.
2. Under Recently Viewed, make note of the highest order number for your E2E Master
Plan Test Orders. Click on the order number of the E2E Master Plan Test Order #2
that you created earlier.
3. Click Clone (either a button or a selection in the dropdown action menu in the
upper right).
4. In the Order Name, increment the number so it’s one greater than the previously
highest order number. (For example, if you noted #6 as the highest existing test
order, name it E2E Master Plan Test Order #7.)
7. In the PRODUCTS panel, find DSL Service and click Add to Cart.
8. In the red notification message, click the Take Me There icon to invoke the
configuration window.
13. Review the Orchestration Plan page. Use your mouse to resize and/or pan the
Orchestration Plan View as needed.
14. Notice blue task color-coding to indicate that the task is in the Ready state.
NOTE:
Depending on timing, the Create Assets auto task may also be blue. Waiting a
little while or refreshing your browser should result in a completed (green)
task state. The order of tasks displayed may differ.
15. Right-click the Credit Check process box and select View Record.
16. In the Credit Check Orchestration Item page, click the edit icon next to the State
field, and select Completed. This will bypass the Credit Check OmniScript and mark
the orchestration item as Complete.
18. Under Orchestration Plan, click the hyperlink for the plan.
19. Back in the Orchestration Plan, notice that all orchestration items are coded in
green and thus in completed state.
NOTE:
Only the E2E Master Plan swimlane is used in this lab. Please ignore the DSL
Service Provisioning swimlane which is used in an upcoming exercise.
21. In the Create Assets Orchestration Item page in the Order Item section, click the
Order/Fulfilment Request link.
22. On the Order page in the order header under Account Name, click White, Noah.
This will open up Noah’s account.
23. In the Account page in the asset management sections, notice the DSL Service
commercial product is now listed as an asset.
NOTE:
● You may see additional commercial products as well.
● The Assetize item implementation assetizes only commercial products
on the order. Technical products are not assetized.
● For information on how to NOT assetize commercial products, please
see the Enterprise Product Catalog training module
Goal
● Sequence order processing tasks using orchestration dependency definitions
Tasks
1. Create orchestration dependency definitions for the E2E Master Plan
2. Test the new orchestration dependency definitions
Time: 15 mins
NOTE:
Dependencies can be further refined using the Scope function, which uses a
containment relationship to set the processing order among orchestration
items from multiple plans.
In your training playground you have four orchestration item definitions included in the E2E
Master Plan. They are in parallel because they have no orchestration dependency
definitions. Now you will sequence them into the following order. This makes sense of
course, as without dependencies, assets get created even if the credit check fails.
Scope Global
NOTE:
The Depends On dependency type specifies that the Dependency Item
Definition, in this case Start Order, must reach a Completed state prior to
processing the linked orchestration item definition, Credit Check. There is no
functional difference between the “Depends On” and “Should Be Processed
Before” dependency types; they simply describe two different logical
approaches: one that looks forward and the other that looks backwards.
BEST PRACTICE:
All dependencies within an orchestration plan definition should use the same
Dependency Type. Although you can mix and match the Dependency Type it
often leads to confusion.
7. Click Save.
8. Click the E2E Master Plan link in the dependency definition that you just created.
NOTE:
Please ignore the Manual Queue Assignment Rules section. It is not used in
this lab.
12. In the New Orchestration Dependency Definition, enter the following information.
Scope Global
14. Click the E2E Master Plan link in the dependency definition that you just created.
18. In the New Orchestration Dependency Definition, enter the following information.
Scope Global
BEST PRACTICE:
The Create Assets orchestration item should occur as the
second to last orchestration item, immediately before Complete Order.
1. Under Recently Viewed, click on the order number for one of the E2E Master Plan
Test Order #’s that you created earlier.
NOTE:
It really does not matter which of the test orders you select and clone. Simply
rename the order by incrementing the number in the order name with the
next highest number in sequence for all of the test orders created thus far.
2. Click Clone (either a button or a selection in the drop-down action menu in the
upper right).
3. Change the Order Name to include the next highest number not yet used (for
example, change test order 7 to 8.)
4. Make sure the Status field is set to “Draft” and then click Save.
6. In the PRODUCTS panel, find DSL Service and click Add to Cart.
7. In the red notification message, click the Take Me There icon to invoke the
configuration window.
9. Click Close.
12. Drag the right side of your browser window to expand the Orchestration Plan page.
13. Notice the Credit Check task is color-coded in blue to indicate that it is in the Ready
state. Also notice that now that the orchestration tasks are sequenced with the
dependencies linking each task, the Create Assets and Complete Order tasks are
greyed out and Pending, awaiting their respective dependent tasks to complete.
NOTE:
Only the E2E swimlane is used in this exercise. (You can ignore the DSL Service
Provisioning swimlane.)
14. Right-click Credit Check and select View Record. In the Credit Check Orchestration
Item page, click the edit icon next to the State field.
15. In the State field, select Completed. This will bypass the Credit Check OmniScript
and mark the orchestration item as Complete
18. Back in the Orchestration Plan, notice that all orchestration items are colored green
and thus in a completed state.
NOTE:
Only the E2E swimlane is used in this exercise. (You can ignore the DSL Service
Provisioning swimlane.)
Depending on timing, the Create Assets may be in a blue (Ready) state. The plan will
dynamically update this, or you can refresh your browser to see the tasks and the plan
advances to a green (Completed) status.
Goal
● Set up external systems used in order processing as orchestration systems
● Define order processing tasks for external systems as orchestration callouts
● Generate JSON output using the DefaultSystemInterface implementation
● Use orchestration item conditions to conditionally trigger the orchestration callout
Tasks
1. Review the installation system orchestration plan diagram
2. Create the Training Mocker orchestration system
3. Create the system interface for the new orchestration system
4. Set up the external system in Remote Site Settings
5. Set the technical product scope to the Default setting
6. Create the installation system orchestration plan definition
7. Create an orchestration callout to the new orchestration system
8. Create the orchestration scenario
9. Test the installation system orchestration plan
10. Change the attribute and check the impact on the orchestration plan
Time: 30 mins
NOTE:
This exercise requires the completion of an earlier decomposition exercise
(Creating Many-to-One Decomposition Relationships).
Before Greg begins building, he first creates a simple diagram of the proposed orchestration
plan definition.
a. Notice the Installation System orchestration plan definition will include one
orchestration item definition, which will be a callout to the Installation Services
System.
b. The new plan will be created with orchestration dependency definitions to the
E2E Master Plan orchestration plan definition so that its callouts task is
sequenced correctly with the E2E orchestration items.
NOTE:
The two Orchestration Plans shown above (E2E Master and Installation
System) are sometimes referred to as simply swimlanes for brevity sake.
Although swimlanes have become fairly ubiquitous technical vernacular, you
can tell they get their name from an aerial view of lanes in a swimming pool.
NOTE:
For training purposes, a Heroku app is used as the downstream fulfillment
system. The app has the bandwidth to respond to multiple students at the
same time without issue.
1. In the Lightning tab navigation bar, click Systems. Note you may have to click More
to expand the drop-down overflow menu, and then click Systems.
2. Click New.
URL https://callouts-mock.training.vlocity.xom
.vloc-dev.com
ALERT:
The URL must be typed exactly as shown and contain no spaces.
4. Click Save.
Task 3: Create the system interface for the new orchestration system
1. Click the Related tab.
Implementation DefaultSystemInterface
Path /mock/aaa
ALERT:
The Implementation and Path must be typed exactly as shown and contain
no spaces.
NOTE:
The Path field is appended to the orchestration system URL to create the final
endpoint URL. By default, the Status is left as None (blank), which is the same
as online.
4. Click Save.
The Implementation field specifies the Apex class used to communicate with this interface.
In this case, the DefaultSystemInterface is used, which is a standard out of the box (OOTB)
synchronous communications interface provided by Salesforce Industries that will generate
the JSON and submit it to the specified endpoint.
ALERT:
Each orchestration system’s endpoint must be established in Remote Site
Settings, or the callout will fail.
2. In the Quick Find box, enter remote (but do not hit <Enter>).
6. Click Save.
Now that Greg has the orchestration system set up, he is ready to create the orchestration
callout. Following best practices, he designs the installation services scheduling callout into a
separate swimlane, which means he needs to create a new orchestration plan definition.
1. In the Lightning search dialog, locate the Installation System Resource technical
product.
4. Click Save.
2. Click New.
3. In the New Orchestration Plan Definition dialog, enter the following information.
Show Order 2
4. Click Save.
Setting Show Order to 2 will place the new orchestration plan swimlane below the original
E2E Master Plan orchestration swimlane.
Greg is the man with a plan—an orchestration plan. Now, he can create his orchestration item
definitions as callouts to the orchestration system. In doing so, he decides to get fancy and
add a condition to his orchestration callout to ensure that customers who select “DIY Install”
do not get scheduled for an installation appointment.
4. In the New Orchestration Item Definition: Callout dialog, enter the following
information.
Scope Global
Number Of Retries 3
NOTE:
If the System Interface is finicky, type in Installation System, followed
by Enter, then select it from the modal window.
5. Notice the Error Queue, which allows you to specify a Manual Queue for any
orchestration items that reach a Fatally Failed state. Also, notice the Vlocity
DataRaptor configuration capabilities, which allow you to transform the JSON
structure of the data being passed to the external system. There are ways to
transform the JSON returned from the external system as well. (Several fields,
including rollback, error queue and retry policies are not used in this lab, but it's
helpful to know they exist for now.)
6. Click Save.
8. Scroll down to the Conditions section, select Single Condition in the No Condition
dropdown.
NOTE:
The following orchestration item condition will ensure that any customers who
select “DIY Install” will not be scheduled for installation; in other words, the
orchestration callout will be skipped and will be displayed in dark gray in the
Orchestration Plan. (Light gray is pending, darker gray is a skipped state.)
Next, Greg will sequence his new orchestration item definition, so that it will occur after
Credit Check and before Create Assets in the E2E Master Plan orchestration plan
definition.
13. In the New Orchestration Dependency Definition, enter the following information.
Dependency Item Definition Credit Check Enter credit and then scroll
down to select it.
Scope Global
In order for this dependency to work correctly, you will also need to adjust the
dependencies of the E2E Master Plan. (Why? Recall there are two swimlanes in play now.
Some tasks within those swimlanes have dependencies on tasks in the other swimlane.
Refer back to the diagram in Task 1 of this exercise for a visual reminder.)
15. In the Lightning tab navigation bar, click Orchestration Plan Definitions.
19. In Orchestration Dependency Definitions using the dropdown action menu, click
Edit next to Credit Check Dependency.
Scope Global
2. Under Recently Viewed, click Installation System to return to the new orchestration
plan definition.
6. Click Save.
NOTE: This orchestration scenario will invoke the new Installation System
orchestration plan when the Installation System Resource technical product is
“added” to the order, which it will by means of the M:1 decomposition
relationships that you created in the Advanced Decomposition Relationships.
2. Click New.
4. Click Save.
6. In the PRODUCTS panel, find the Back to School Student Offer product, and click
Add to Cart.
7. In the red notification message, click the Take Me There icon to invoke the
configuration window.
8. Set the DSL Service’s Download Speed attribute to 40 Mbps and the Home Hub
Modem’s Grade attribute to Best.
9. Click Close.
Notice that the Order Line Item (OLI) on the Source Order decomposes to an Installation
System Resource fulfillment request with an Add action. This is the product (Installation
System Resource) and action (Add) you set up earlier for the Orchestration Scenario in the
Installation System swimlane.
12. Review the Orchestration Plan page (E2E Master Plan and Installation System
swimlanes).
13. Look at the top two swimlanes (E2E Master Plan and Installation). Notice the new
Schedule Installation task in the Installation swimlane. The Credit Check task is
color-coded in blue to indicate that it is in the Ready state, and because of the
dependencies that you created, the rest of the tasks are grayed out and Pending,
awaiting Credit Check to reach the Completed state.
NOTE:
The DSL Service Provisioning swimlane is not used in this exercise. You can
ignore it.
14. Right-click the Credit Check process box and select View Record.
15. In the Credit Check Orchestration Item page, click the edit icon next to the State
field.
16. In the State field, select Completed. This will bypass the Credit Check OmniScript
and mark the orchestration item as Completed.
19. Back in the Orchestration Plan, all of the orchestration items should be green and
marked Completed.
NOTE: If the orchestration plan is not all green (completed), please wait a few
seconds. Sometimes the assetization performed by the Create Assets auto
task takes a few seconds. If it is gray (skipped) then revisit the conditions logic
for the Schedule Installation task configured earlier. The operator may not
have been changed to not equals (!=) or the condition may not have been
saved.
NOTE:
The DSL Service Provisioning swimlane is not used in this exercise. You can
ignore it.
Greg thinks this is the bomb, but he wants to take a look at the call and response of the
orchestration system. First, he looks at the orchestration item to find out more details about
its run-time instance.
20. Right-click Schedule Installation and select View Record. In the Schedule
Installation orchestration item page, notice the Execution Log, which indicates the
orchestration callout’s state.
Of course, if execution fatally fails, that would be shown as well. For example, the callout
system is in need of a restart, and the number of retries configured earlier all fail, the
Execution Log would look similar to the following.
22. Review the Fulfilment Request Line Detail, which displays the JSONAttribute for the
fulfillment request line item.
Finally, to close the loop, Greg queries the orchestration system URL directly, to see the
fulfillment request data that was posted during orchestration.
24. Open a new browser tab and enter the following URL.
https://callouts-mock.training.vlocity.xom.vloc-dev.com/
25. Using your browser’s Find (CTRL-F) function, paste the line number id from your
buffer to the search dialog, and find your training playground’s request on the
Training Mocker server.
26. Notice the Installation System Resource product attributes that have been formatted
into JSON and passed via the Training Mocker orchestration system.
NOTE:
The Training Mocker is a shared resource so you may see more traffic than just
your request/response.
Task 10: Change the attribute and check the impact on the
orchestration plan
In the previous task, you tested the Installation System orchestration plan by placing an
order. Recall that the condition placed on the Installation Type attribute is whether or not it
equals “DIY Install”. In the previous task, you left this attribute as the default “Full Service
Install” and observed the orchestration plan. In this task, you will change the Installation
Type attribute to “DIY Install” and observe the impact on the new orchestration plan.
1. Create a new order, this time name it Installation System Test Order #2.
(You can use the same account name, B2C price list, etc.)
3. Use the Take Me There icon in order to set the DSL Service’s Download Speed to 40
Mbps, and the Home Hub Modem’s Grade attribute to Best. (Notice this is the same
as the prior test order thus far. The next step will make a change, however.)
5. Close the configuration, and then click Decompose Order. Notice the Installation
Type attribute on the fulfillment request is “DIY Install”. (In the previous order it was
“Full Service Install”.)
7. To advance the plan, change the State for Credit Check from Ready to Completed.
You will see an orchestration plan like the following, with the Schedule Installation task
marked Skipped. Recall that the condition set up earlier was that the Schedule Installation
callout should only be invoked if the installation type was not equal to “DIY Install”. For this
order it was set to “DIY Install” so the callout was skipped. The remainder of the tasks in the
plan should progress to a completed state.
NOTE:
The DSL Service Provisioning swimlane is not used in this exercise. You can
ignore it.
Goal
● Confirm Industries Order Management is configured to support integration retries
● Run the Integration Retry batch job in XOM Administration
● Distinguish between Failed and Permanently Failed callouts
● View the Execution Log when callouts fail
● Create, configure, and test Integration Retry Policies
● Use Manual Queues for fallout management and escalations
● Verify the integration retry job is scheduled to run
● Configure and test setting the mode (online/offline) of a system interface
Tasks
1. Confirm configuration supports retry policies
2. Reconfigure the Path and place a test order
3. Reconfigure the System URL and place a test order
4. Additional fallout management configuration
5. Test retry policies with fallout queues
6. Repair IOM configuration and test DNS
7. Take a System Interface offline
Time: 60 mins
Recall that callouts are a type of orchestration item (or task) used for exchanging
messages with external systems that participate in order fulfillment. Sometimes callouts
fail and that's where Integration Retry Policies play a critical role.
Integration Retry Policies allow you to configure basic behavior for failed callouts to third
party fulfillment systems. This gives you increased control over IOM behavior when callouts
fail. For example, you can configure a policy to retry a failed connection ten times, with an
interval of one minute between attempts. In this scenario, after ten failed attempts over
roughly ten minutes, IOM orchestration changes the callout to a fatally failed state in the
orchestration plan and can add an entry into a specified manual queue.
Additionally, once Integration Retry Policies are configured, they may be used by many
different Callouts from multiple orchestration plans. Create and configure them once, use
them as often as you like. Easy peasy, efficiency pefficiency. (Granted - those are not real
words but you get the idea!)
Without retry policies Communications Service Providers (CSPs) have less control over what
IOM can do when callouts fail. For example, without policies you can specify the successive
number of retries, but no interval between retries.
1. Click Setup.
6. Click OrchestrationMode. The name/value pair is displayed for this custom setting.
ALERT:
OrchestrationMode must be set to PlatformEvents for Integration Retry
Policies to work.
4. Click Save.
The Path is appended to the System’s URL to specify the API endpoint for communication.
Changing the endpoint to something “bogus” (incorrect) will certainly impact orchestration.
6. Click New.
8. Click Save.
10. In the PRODUCTS panel, find the Back to School Student Offer product, and click
Add to Cart.
11. In the red notification message, click the Take Me There icon to invoke the
configuration window.
12. Set the DSL Service’s Download Speed attribute to 40 Mbps and the Home Hub
Modem’s Grade attribute to Best.
15. Click the link icon for Installation on the source order. Notice it decomposes to
Installation System Resource (fulfillment request line).
17. Change the State to Completed for the Credit Check manual task. This will advance
the progress of the executing orchestration plan.
NOTE:
The DSL Service Provisioning swimlane is not used in this exercise.
19. Hover over the task header for the failed callout (but don’t click it yet). The callout is
in a Fatally Failed state, as indicated by the red color, the hover text, and the “!” icon
in the header.
There are a few subtleties from the log worth noting as this exercise progresses,as noted in
the bold text in the example log.
● Even if IOM can connect to a third party system, an HTTP 404 response (page not
found) fails immediately regardless of what the Number of Retries is set to, and
whether or not there is an Integration Retry Policy in place.
● A HTTP 404 response is categorized as fatally failed. Fatal failures are manually
recoverable, but not recoverable by the system.
● Please see the documentation for more information on HTTP response codes and
IOM behavior based on the HTTP responses.
If breaking one thing is helpful, then is breaking more things even more helpful? Perhaps
not in real life, but simulating common system failures can provide additional learning, so
here it goes!
5. Click Save.
8. Click Save.
You just repaired the Path, and changed the system URL to simulate a connection failure to
a third party fulfillment system. More specifically, the domain specified in the URL field used
to resolve to a valid IP address, so IOM could indeed connect to it. Appending the “1” to the
valid domain name will prevent future connection attempts from succeeding.
10. Enter Broken System URL Test Order for the new order’s Name. Fill out the
remainder of the order like you did in the previous Task of this exercise.
TIP:
Refer to the previous Task if you don’t recall how you placed the Back to
School Student Offer.
11. Once the order is configured in the cart, click Decompose Order.
12. Click View Orchestration Plan. Progress of the orchestration plan halts when the
Credit Check task reaches a Ready state.
13. Duplicate the browser tab so you have two tabs viewing the executing orchestration
plan.
14. In one of the executing orchestration plan tabs, change the State to Completed for
the Credit Check manual task.
15. Quickly flip back to the other tab with the executing plan. Refresh the browser and
notice the Schedule Installation task.
Although the callout failed again, notice the looping arrow in the task header (not the “!”
like the previous test). In the previous test the callout failed immediately (due to a HTTP
404 response), and retries were not even attempted. This time the configured Number of
Retries is being attempted. (The execution log is being updated during each retry as well.)
NOTE:
Depending on your timing and the system and network response, you may
miss the looping arrow icon in the task header.
16. Wait a few more seconds and refresh your browser. If the retry attempts have already
exceeded the maximum set (3 in our case), then the looping arrow will change to a
“!” again.
17. Right-click the failed Schedule Installation callout and select View Record.
● The Actual Number of Retries (3) violated the Maximum Number of Retries (3).
● The Execution Log reveals the retry attempts. (Four total attempts. The initial
attempt and three retries before exceeding the maximum setting of 3.) The
date/time stamp shows the retry attempts happen in rapid succession. There is no
delay between retry attempts.
● Once the orchestration item is over the maximum retry limit the State is changed to
Fatally Failed.
The current configuration works fine for some orchestration plans, but there are limitations
that Greg hopes to address. For example, executing all retries without delay lacks control.
(Greg has been known to be a bit of a control freak when it comes to Fallout Management.)
In the next Task you will further configure IOM’s fallout management including retry
policies.
3. Notice the Fallout Error Queue. This queue was created for you during the
installation/upgrade process.
5. Click Save.
NOTE:
Algorithms associated with the Queue Type apply to Manual Tasks only. They
do not apply to failed Callouts. The Queue Type does not apply to this exercise
regardless.
One queue is for fallout errors, the other queue is for escalations. This is a simple example
of how you can use queues to assist with operations concerning fallout management. Now
you will create an Integration Retry Policy, then associate it with the Schedule Installation
callout for further testing.
6. Open up the App Launcher, enter integration and select Integration Retry
Policies.
7. Click New.
Selecting Monotonous Forever Retry Policy tells IOM not to place a maximum on the
number of retry attempts. Setting the maximum retries will place an upper limit and make
the testing more interesting.
With the policy in place, there are still two simple configuration tasks before you can test it:
11. Navigate to Orchestration Plan Definitions > Installation System and click on
Schedule Installation.
12. Scroll down to the Callout section and make sure it’s expanded. There are two
changes to make before saving your changes.
14. Click in the Retry Policy field and select 2 Retries every 60 seconds.
17. Click Save. Now the retry policy you created earlier is associated with the Schedule
Installation callout you have been testing in this exercise.
ALERT:
Once a Retry Policy is put in place, the Number of Retries field is overridden.
No matter what the individual Callout’s Number of Retries is set to, it will be
ignored. In our example, the initial attempt and two retries will be attempted
approximately 60 seconds apart based on the policy you just put in place.
18. In the Lightning tab navigation bar, click Vlocity XOM Administration.
NOTE:
If you don’t see the option, click the More dropdown in the Lightning tab
navigation bar and select it from the list.
19. Locate the Schedule Integration Retry Job and click its Start button.
As time passes you may spin new orgs and wonder if you already started the integration
retry job or not. There are three things to realize:
● If you return to the XOM Administration screen and click the Start button, the
system performs a check and lets you know it’s already scheduled.
● If the retry job is already scheduled, the Start button will toggle to Stop. Clicking Stop
will remove the job from the Scheduled Jobs queue.
● You can check All Scheduled Jobs in Setup to see if it’s scheduled to run.
It’s 5:00 pm and Greg is getting a bit tired. The last scheduled job entry shows the IOM
Integration Retry Job is scheduled to start in one minute! That’s a relief.
TIP:
In this Task you created a new Integration Retry Policy, then later associated it
with a callout. When you create a new callout, you can select the + New
Integration Retry Policy. This will create and associate the callout with the
new policy in a single step.
2. Enter Retry Policy for the new order’s Name. Fill out the remainder of the order
like you did in the previous Tasks of this exercise. Once the order is configured in the
cart, click Decompose Order.
3. Click View Orchestration Plan. Progress of the orchestration plan halts when the
Credit Check task reaches a Ready state.
The circular arrow in the task header indicates retries are being attempted. (You may catch a
glimpse of it being in the Ready state before it fails. Either wait a short while or refresh your
browser once or twice.)
6. Right-click the failed Schedule Installation callout and select View Record.
7. View the Execution Log. The callout failed, and is queued for a retry. (Hint: Leave the
failed callout in a browser tab so you can periodically refresh and view changes to
the log.)
8. Click the Fallout Error Queue hyperlink below the Error Queue field. Depending on
your timing, the error queue is probably empty. Why? It will take a few minutes for
the initial attempt and retries to fail and exceed the maximum specified in the retry
policy for the failed callout. An entry is not added to the error queue until the
maximum number of retries is violated.
9. Refresh the Execution Log again. Eventually the maximum retry limit is exceeded.
The log shows the initial callout failure, being queued for several retry attempts, and
eventually the maximum retry limit specified in the retry policy is exceeded.
The Schedule Installation callout is in a Fatally Failed state. In your Training Playground
there is only one entry. In production, there could be dozens, hundreds, or even more
entries in the queue. Greg remembers that he created another manual queue for
escalations to the management team. He’ll check out that process next.
11. Return to the executing orchestration plan. You may need to refresh your browser
too.
The “!” in the task header confirms the callout is in a Fatally Failed state. Fatally Failed tasks
require manual intervention to resolve. The system will not recover on its own.
12. Return to the Fallout Error Queue. Select the Schedule Installation checkbox for
the queue entry, click Assign To Queue and select Fallout Escalations from the
Search Objects field. Click Assign.
The fatally failed Schedule Installation callout has been moved from the Fallout Error Queue
to the Fallout Escalations queue. In a production environment configured with similar
manual queues only a handful of failed callouts would be escalated to the management
team.
4. Delete the “1” at the end of the System URL. (It should be
https://callouts-mock.training.vlocity.xom.vloc-dev.com when done.)
5. Click Save.
MAC users
Run the host utility from a Terminal window/Linux shell. On a Mac, this is typically reached
from: Launchpad > Other > Terminal.
% host callouts-mock.training.vlocity.xom.vloc-dev.com # Correct hostname
callouts-mock.training.vlocity.xom.vloc-dev.com is an alias for
a6118f1d76e4411ea83c50a574b031de-1634311352.us-west-2.elb.amazonaws.com.
a6118f1d76e4411ea83c50a574b031de-1634311352.us-west-2.elb.amazonaws.com has address 52.42.57.32
a6118f1d76e4411ea83c50a574b031de-1634311352.us-west-2.elb.amazonaws.com has address 52.37.150.62
a6118f1d76e4411ea83c50a574b031de-1634311352.us-west-2.elb.amazonaws.com has address 35.161.116.0
% host callouts-mock.training.vlocity.xom.vloc-dev.com1 # Bad hostname
Host callouts-mock.training.vlocity.xom.vloc-dev.com1 not found: 3(NXDOMAIN)
PC Users
Run nslookup utility from the Windows Shell. First on the correct hostname, then on the
incorrect hostname.
The DNS request for the incorrect hostname times out, and never resolves (non-existent
domain).
TIP:
Callouts that are in an On Hold state don’t attempt to connect to fulfillment
systems. This reduces network traffic and prevents many (dozens, hundreds or
even thousands!) of items being added to fallout queues. Network traffic is
reduced particularly if the callout has a monotonous forever integration retry
policy in effect. Setting the System Interface to offline prevents wasteful
network traffic and potentially massive numbers of entries in fallout queues.
ALERT:
Platform Events mode is required for this feature to work.
5. Click Save.
NOTE:
There is a housekeeping task at the end of this Task to set the Status back to
online. Neglecting to do so could impact future exercises.
7. Click New, then in the New Order page, enter the following information.
8. Click Save.
9. Configure the order. Enter Flex DSL Service and click Add to Cart.
10. Click Decompose Order. Notice this test order contains multiple levels of
decomposition, as indicated by three columns. (The Orders column and two
Fulfillment Request columns.)
11. Click View Orchestration Plan. Progress of the orchestration plan halts because the
Consumer Credit Check task is in a Ready state.
12. Right-click on the Consumer Credit Check task and select Complete Item.
13. Similarly, click Complete Item for the other billing dependency (Test DSL Service).
14. Notice the task header for Update Billing includes an index finger icon.
The State is On Hold. For as long as the Update Billing Interface is offline, similar orders that
result in the same orchestration will prevent the callout from even attempting to connect to
the billing system. In the interest of time, you will set the interface status back online and
confirm the orchestration plan continues to completion. (There is no need to wait for an
actual two hour maintenance window!)
16. Return to Systems > Billing > Related tab > Update Billing Interface.
17. Edit the Status field. Change it to Online, and click Save.
18. Return to the executing orchestration plan. Depending on timing, the Update Billing
task is no longer On Hold and is either in a Ready state, or already Completed. (If
not, refresh your browser. The Update Billing callout should be Completed.)
Goal
● Describe what Push Events are
● Explain a common use case for using Push Events
● How to create, configure and incorporate Push Events into an orchestration plan
● How to test a Push Event
Tasks
1. Create an Orchestration Plan Definition
2. Create Orchestration Item Definitions
3. Create a Test Order
4. Test the Push Event (JSON)
5. Test the Push Event (Apex)
Time: 45 mins
Push Events pause execution in an orchestration plan by remaining in a Ready state until a
specific condition evaluates to true. Once the condition becomes true, execution progresses
again, and the status is changed to Complete. Conditionality is configured in the Event
Condition section of the Push Event. The mechanics of configuration is the same as other
parts of the Order Management application.
Since Greg just spun up a new dev&test org that includes a basic product model for a new
music service, he decides to do some Push Event prototyping leveraging Spotify.
His ideas for a test orchestration plan are also straight forward. One Orchestration Plan
Definition (e.g. plan), three Orchestration Item Definitions (e.g. tasks), with two
Orchestration Dependency Definitions (e.g. dependencies), all within a single swimlane.
2. Click New.
3. In the New Orchestration Plan Definition dialog, enter the following information.
Scope Global
Show Order 1
4. Click Save.
5. Click New in the Orchestration Scenarios section, and in the New Orchestration
Scenario dialog, enter the following information.
Action Add
6. Click Save.
Now you are ready to add three tasks (Orchestration Item Definitions) to the single
swimlane.
● Use the Save & New option (easy to forget this quick tip)
● Create Milestones only (you will see why shortly)
1. Create three new Milestone Orchestration Item Definitions using the following
names:
● Start VAS
● Push VAS
● End VAS
All other fields can use the default values.
2. Click on Push VAS in the Orchestration Item Definition Name list to change the
task.
TIP:
Using Milestones when initially configuring your orchestration assets is quick
and easy. Once the scenarios, conditions, and dependencies test out ok, you
can convert the record type to the appropriate type.
3. Click the Change Record Type icon. Change it from Milestone to Push Event. Click
Next then Save.
4. Scroll down to the Event Conditions section. Click Single Condition from the No
Condition dropdown. Enter the following information and click Save Conditions
when ready.
Operator =
If the value for the Install Account Name technical attribute is changed to “Push Test” for
any reason, the condition becomes true and the paused Push Event task will execute. Its
status will change to Complete as well. Reminder: Greg is simply testing to gain a better
understanding of Push Events. To do so, an existing product model is leveraged. A
production system would not use an Install Account Name of “Push Test”. (Well, it sounds
like an odd name to Greg anyway.)
5. Switch to the Related tab and add a new Orchestration Dependency Definition.
Leave the other fields at their default value. Remember to click Save when through.
6. Edit the End VAS task you created earlier. Switch to the Related tab and add a new
Orchestration Dependency Definition.
7. Click Save. (Leave the other fields at their default values.) Only two dependencies
are needed for the Push Event test, so you are ready to place a test order. The image
below shows a quick review of what you just built out.
● One Orchestration Plan Definition with a single swimlane (Test Push VAS)
● Two dependencies (Start VAS Dependency, VAS Push Test Dependency)
● Three Orchestration Item Definitions (Start/End VAS Milestones and one Push Event)
2. Select Carole White for the Account Name. (Set the Price List to B2C and use today
as the Order Start Date. As always, remember to click Save when ready.)
3. Select Configure Order from the Power Launcher and add Spotify to the cart.
4. From the dropdown, click Configure and add the following information.
Number of Accounts 5
The values really don’t matter at this point, and apologies for the “Peter Paws'' pun. Your
order should look similar to the screenshot below.
5. Once settled, click Decompose Order. The decomposition has three basic
mappings.
The start milestone has completed, and the orchestration plan has paused on Push VAS. It
is waiting on an event.
ALERT:
If your Push VAS is dark gray (Skipped) and End VAS has completed, then your
push event is likely configured wrong. Return to the Push VAS task, expand
both the Event Conditions and Conditions section. Event Conditions should
have one simple expression in it. Conditions should be blank. If it is not blank,
your push event will be skipped.
7. Hover over the Push VAS title for the task. Notice although it is waiting for an event,
the task state is Running.
While this is a basic example, realize that this swimlane could have more tasks, and be used
in a larger orchestration plan with additional swimlanes. All tasks that have dependencies
on Push VAS will never start running until its Event Condition evaluates to true. It’s time to
test that out.
NOTE:
Be sure to click the FRL itself, which includes the line item action (Add). If you
clicked the actual Product link, go back and try again. Depending on timing,
your fulfillment Status may be in progress.
3. Click the Edit JSONAttribute pencil icon in the Details tab for the FRL.
4. Use the corner handle to scroll out a larger display for the raw JSON, then replace
the first occurrence of Peter Paws text with Push Test. (It should be near the end of
the JSON.) Before saving your edits, make sure you have a separate browser tab for
the executing orchestration plan.
TIPS:
You can place your cursor near the top of the JSONAttribute window and use
^F (Control-F) and enter “Peter” in the browser search field. That will locate
the first occurrence of “Peter” in the JSON. If you want to see the JSON
formatted, please use a website such as www.jsonlint.com. Copy/Paste your
JSON and click Validate JSON.
5. Click Save and switch to the browser tab that has the running orchestration plan.
The trigger set for the Push Event re-evaluates the Event Condition, changes the Push VAS
task state to Complete and allows the dependent task to execute. (Note this can take ~15
seconds or so. A browser refresh speeds things up.)
This manual test by changing the JSON manually is simple and effective but not very
realistic. A more common way to have an Order Item or Fulfilment Request Line change is
through custom Apex code.
NOTE:
If the prior Push Event test worked to your satisfaction, and you have no time
or interest in running Apex code as another test, you can treat this Task as
optional.
1. Place a similar test order as you did earlier. Simply append a number to the end of
the Order Name (Test Push VAS 2). Just as you did earlier, add Spotify to the cart
and configure the order. The value for the Number of Accounts, Subscription Type,
and Install Account Name do not matter for this test.
3. Click the Spotify RFS Fulfillment Request hyperlink that includes the Add action.
4. Copy or make note of the LineNumber in the Details tab. You need the
alphanumeric string to the left of the “.” and can disregard from the “.” to the right.
In the example above, a1d2x00…AAC (the “.0001” should be stripped out). You will need
the LineNumber shortly.
5. Return to the order decomposition screen and click View Orchestration Plan.
Execution is paused at the Push VAS task. Keep a browser tab open with the
executing orchestration plan.
6. From a separate browser tab, click the Setup (gear) icon, then select Developer
Console.
8. Paste the Apex snippet below inside the Enter Apex Code window.
ALERT:
Make sure the Enter Apex Code window is wide. It tends to help with the
encoding/formatting of the code after you paste it into the window. In
particular, sometimes the CR/LF (Carriage Return/Line Feed) can get confused
and what should be a single line turns into multiple lines resulting in a syntax
error when executed. There are 6 lines of code, each line ends with a
semicolon (;).
vlocity_cmt.XOMOrderItemService xois = (vlocity_cmt.XOMOrderItemService)
vlocity_cmt.XOMObjectFactory.getService(vlocity_cmt__FulfilmentRequestLine__c.S
ObjectType);
vlocity_cmt.XOMOrderItemDomainObject frl =
(vlocity_cmt.XOMOrderItemDomainObject)
xois.getObject(Id.valueOf('LineNumber'));
vlocity_cmt.XOMAttributeValueRT av = frl.getAttributeValue('ATT_DC_IN');
av.setValue('Push Test');
frl.updateObject();
vlocity_cmt.XOMObjectFactory.commitObjs();
9. Notice the LineNumber in red font. That is placeholder text, and the code actually
requires the LineNumber you made note of earlier.
Make sure your lines look similar. Each line of code ends with a “;”. (There are 6 lines total.)
10. Change the LineNumber text to the unique value of your LineNumber.
11. Click Execute. You will see a message “Sending Request”. It may take a few seconds
for the code to complete… and the Logs tab entry to change the Status to Success.
12. Change back to the browser tab running your orchestration plan. Just like before, the
change to the FRL should trigger re-evaluation of the Event Condition. The push
event and remainder of the plan should complete.
NOTE:
Your actual FR number will reflect the new orchestration plan, otherwise it will
look similar to what you observed earlier.
Time and interest permitting, place additional test orders and further test out Push Events.
When satisfied, remember to close out the Developer Console in your browser.
When you are through, please perform the following housekeeping task:
● Navigate to the Test Push VAS Orchestration Plan Definition and delete the Spotify
RFS Push VAS Test Scenario Orchestration Scenario.
This will keep the swimlane from triggering during the upcoming MACD lab exercise.
Goal
● Step through the design process for several MACD scenarios
● Configure order orchestration to support MACD for add and modify actions
● Create an Orchestration Scenario Condition
● Perform end to end tests of MACD
Tasks
1. Review whiteboards, post-it notes and diagramming
2. View the product model
3. Create orchestration plan definitions
4. Configure the end-to-end (E2E) swimlane with add and modify actions
5. Configure the provisioning swimlane with add and modify actions
6. Configure the billing swimlane with add and modify actions
7. Configure the assetization swimlane with add and modify actions
8. Configure the SMS welcome swimlane with an add action
9. Configure the SMS upgrade swimlane with a modify action
10. Create the orchestration dependency definitions
11. Add a new order
12. Change an order
13. Perform additional change order testing (optional)
Time: 2 hrs
What is MACD?
MACD stands for Move, Add, Change, and Disconnect (or Delete) actions. These actions are
applied to order line items, and they are used to describe what is happening to each line
item. Is this product or service moving to a new service location? Or perhaps the customer
wants to change the service in some way, such as an upgrade that takes advantage of new
and improved technology? Or is this product or service being disconnected?
Far and away the most common action is “add”. For that reason, Industries Order
Management training has already covered add orders. However, now it’s time to learn about
other actions, and how they are used within orchestration plans in order to fulfill orders.
NOTE:
In the interest of time, the training playground has pre-configured the product
model and the decomposition relationships required for MACD orders. That
way, the labs can focus on the new key concepts of MACD: orchestration.
Sometimes using low-tech whiteboards with post-it notes and stick-figure diagrams during
the planning stage helps bypass issues during the design phase. For some, they lend
themselves to a fast pace, where the thought process goes unhindered by a lack of
proficiency with graphic design tools or typing speed.
Greg is a runner. He always stretches before he runs. Since he is new to MACD, and still a bit
rusty after vacation, he begins flushing key thoughts and principles onto a whiteboard with
post-it notes.
After meeting with the product marketing and product management teams, Greg has
several ideas floating about. He decides to diagram a few possibilities as he continues to
narrow in on implementation ideas.
Since Infiwave plans to initially roll out a single music service, the 1:1 decomposition for
simple MACD operations should work nicely.
There are hallway conversations going on at Infiwave that suggest if the single music service
is a hit (no pun intended) then additional music services will be offered. This model works
nicely for that and is a sensible transition from the one-to-one model shown earlier.
There is a rumor at Infiwave that the leading candidate for the Sr. Director role of Greg’s
department is a long-time TMForum member and sits on one of the advisory committees as
well. So, Greg diagrams a multi-level decomposition model for simple MACD operations as
well. This model includes both CFS and RFS layers, which operate as an abstraction in the
middle. It has potential if either the commercial or technical products are likely to expand
and/or contract as time goes on. Some may argue this model is pedantic, yet others that it’s
a very elegant solution. Regardless, Greg has a few options in mind and feels more prepared
to discuss with management and other team members. (Although referred to here as a
“TMForum/SID Model”, it is not to imply the other models are not SID compliant as well.
This model is just more thorough, and something you would expect to see in a
TMForum/SID documentation page or presentation.)
TIPS:
Although MACD requires careful consideration end-to-end, often designers
need to place a higher priority on the downstream systems (and their
capabilities) and work their way backward. Ultimately, their capability and
functionality affect the design of your orchestration plans.
1. Use the Vlocity Product Console to look at the Spotify commercial product. View
the General Properties and Attributes and Fields facets. Several attributes will be
included in decomposition (Number of Accounts, Spotify Subscription Type, Install
Account Name).
2. Similarly, use the Vlocity Product Console to look at the Spotify RFS technical
product.
3. Use the Products tab to view the decomposition relationship between Spotify and
Spotify RFS. Notice the decomposition attributes in the Mappings Data. Condition
rules are not required for this exercise.
4. Look at the logical orchestration view of the 1:1 decomposition model below. This
logical view places emphasis on the MACD actions (add, modify, disconnect)
supported for the Spotify music service product offering.
Each lane corresponds to a line item action set in the orchestration scenario: Add, Modify
and Disconnect.
In our example, it is assumed that the music provisioning system supports an UPSERT
operation. (That is, pass all of the information for Spotify provisioning. If the named account
already exists, then update it. If it does not, then create a new one.) For Billing, it is assumed
that every time an account is added, modified, or disconnected, billing for the account is
either activated or deactivated.
NOTE:
Don’t confuse this logical view with the actual swimlanes that will be
generated during orchestration. This view is meant to help with the actual
design of orchestration assets, but the actual executed orchestration plan will
differ from the logical view. (Some may prefer to sketch out and diagram the
proposed swimlanes for the orchestration plans as well as another design pass
before building out the orchestration assets on the platform.)
NOTE:
“Discontinue” is sometimes used within the industry synonymously with
“Delete” and “Disconnect” actions.
Although you could place an order for Spotify, and decompose it, orchestration is not in
place… yet.
With some background on MACD, brainstorming, a look at what is already set up for you,
and different views of what needs to be set up, it’s time to configure orchestration for a
basic Spotify music service.
TIPS:
For rapid prototyping of orchestration plans, you can use Milestone tasks for
all but the assetization auto-task. This helps with design, test, modify and
re-test efforts that often accompany orchestration plans, scenarios, conditions,
etc. In a production environment, these would have to be converted to
manual tasks, callouts, etc.
1. Create new Orchestration Plan Definitions. Use the list below for plan names. Make
sure the Scope is Global.
Spotify E2E 1
Spotify Provision 2
Spotify Billing 3
Spotify Assetize 4
TIPS:
Use the Save & New option to quickly loop through creating new plan
definitions. (Several other orchestration assets allow for this option as well. A
handy time saver when you need to create several.)
Each plan will need one or more Orchestration Item Definitions (e.g. tasks) within it. You’ll
add and configure tasks for each swimlane next.
NOTE:
The swimlanes above are for add and modify actions only. You will deal with
disconnect actions later on.
Task 4: Configure the end-to-end (E2E) swimlane with add and modify
actions
1. For the Spotify E2E swimlane, create two new Milestone tasks. For the first task, use
the following information:
Scope Global
Scope Global
Although no additional tasks are needed, the Orchestration Scenario for this swimlane is
critical. Recall the logical view for the add and modify actions. You will set those next.
2. Create a new Orchestration Scenario for Spotify E2E. Enter the following
information.
ALERT:
The default Action is Add. Up until now, all orchestrations have been
exclusively for Add actions. Be sure to select Modify from the Available
column, and then click the right arrow to move it into the Chosen column.
3. Click Save.
Each time the Spotify commercial product is placed in the cart, and the order decomposed,
the Spotify E2E Scenario will trigger the generation and execution of a new orchestration
plan with an E2E swimlane, based on the Add or Modify line item actions.
Scope Global
TIPS:
You are encouraged to create naming conventions that work for your
organization. Consider using a noun + verb. (Create Account, Provision
Account, Set Profile, etc.) Although for the training playground we use the
fulfillment system itself in the name, it can be advantageous to omit it. (For
example, if legacy systems are replaced, not having the system name within
the task name can simplify configuration changes.)
When the Spotify commercial product decomposes to Spotify RFS with either an add or
modify line item action, the provisioning swimlane will be executed.
Task 6: Configure the billing swimlane with add and modify actions
Billing is a bit more complicated to configure.
1. For the Spotify Billing swimlane, create two new Milestone tasks. Name them
Spotify Billing Activate and Spotify Billing Deactivate. Set the
Scope to Global.
3. Scroll down, and under the Conditions section, click OR from the No Condition
dropdown. This will place two single conditions for you to complete.
Operator =
Value Premium
Operator =
Value Family
Confirm the condition for the simple expressions is set to OR, then click Save Conditions.
5. Click on the link Spotify Billing. This will redirect to the Spotify Billing Orchestration
Plan Definition page.
7. Scroll down, and under the Conditions section, click Single Condition from the No
Condition dropdown. Enter the following information for the other expression:
Operator =
Value Free
10. Create a new Orchestration Scenario and add following information and click Save.
12. Scroll down, and under the Conditions section, click OR from the No Condition
dropdown. This will place two Single Conditions. However, this time you actually
need three. Click the + to add the third part of the expression.
13. For the first Single Condition, use the following information:
Operator =
Value Free
14. For the second Single Condition, use the following information:
Operator =
Value Premium
15. For the third Single Condition, use the following information:
Operator =
Value Family
Confirm your expression is correct and click Save Conditions when ready.
With this configuration, each time an account is created or modified, billing for that account
will be either activated or deactivated. The orchestration scenario condition makes sure the
subscription type is Free, Premium or Family, then the individual tasks are conditionalized to
either activate (Premium, Family) or deactivate (Free) billing. (This will become more
apparent later when testing MACD. Essentially, it will function similar to a toggle. One task is
executed, the other is skipped, depending on the subscription type.)
NOTE:
This configuration may not be common, but it can be helpful in certain
circumstances. For example, if it’s an inexpensive operation. If the payload for
such an operation was huge, or access to a legacy system sluggish, then this
configuration could be seen as inefficient.
Scope Global
Product Spotify
Assetization should take place every time a product decomposes to Spotify, and the action
against the account is add or modify.
ALERT:
The Product must be a commercial product, not a technical product for the
scenario that executes assetization. (In this case, Spotify, not Spotify RFS.)
If you attempt to assetize a technical product, you will observe the following in the
assetization swimlane and the task’s execution log:
Action Add
No scenario conditions are needed. However, note that this scenario should only trigger if
an account is added. A modify or disconnect should not send a welcome SMS message.
Action Modify
Be sure to remove the default Add action and add the Modify action to the scenario before
clicking Save.
4. Scroll down to the Conditions section, click OR from the No Condition dropdown.
This will place two Single Conditions for you to complete.
Operator =
Value Premium
Operator =
Value Family
BEST PRACTICE:
Recall it’s considered a best practice to configure dependencies last.
For each dependency below, set the Scope to Global, and leave the Dependency Type as
the default Depends On. (Remember that dependencies are set from the Related tab of
each task.)
1. For the Spotify E2E plan, create a dependency for the Spotify End task. Just prior to
completing you want assetization to take place.
2. For the Spotify Provision plan, create a dependency for the Spotify Provision task.
Once E2E has triggered, both provisioning and billing tasks should execute in
parallel. They do not have dependencies on each other. Because there are several
tasks that depend on Spotify Start, a basic naming convention is deployed: <Task> -
<TaskItDependsOn>.
3. Similarly, create dependencies for both tasks in the Spotify Billing plan.
4. Create dependencies for the Spotify Assetize task in the Spotify Assetize plan.
Assetization should occur whenever a billing or provisioning task executes.
(Information for all three dependencies are in the table and screenshot below. Tip:
You can use the Save & New button to save time.)
5. Lastly, create dependencies for the SMS messaging tasks in their respective
swimlanes. SMS messages should be sent out once provisioning is complete.
ALERT:
Because you will likely check Service Assets on the account you place the
order for several times, consider creating a new account each time you test
MACD. It will guarantee a fresh account and eliminate potential confusion
with multiple orders for multiple accounts with multiple assets. Use a basic
alphabetic convention starting with an account with initials “A. A.” (e.g. Alan
Abrams), then “B.B.” (Beatrice Barnes), and so on.
Creating a new account with the order simplifies testing, particularly for checking account
assets.
2. Select Configure Order from the Power Launcher and add Spotify to the cart.
3. Use the Configure option from the dropdown menu to set the attribute information.
Number of Accounts 1
Install Account Name Enter any name you like. (This attribute is
mapped in decomposition, but not used in
any conditions, and is not required. You can
use it as a primary contact name, or a
unique/fun account name to make locating
the correct asset even simpler.)
Notice that Spotify (commercial product) decomposes to Spotify RFS (technical product).
Both are based on the “Add” line item action. The technical attributes all map through
ad-verbatim. Depending on timing, you may or may not see an Asset/Inventory item as part
of the fulfillment request for Spotify RFS. If you do not see the asset, wait a few seconds and
refresh your browser. (It will only be there after the Assetization in the orchestration plan
completes without failure.)
NOTE: The Install Account Name attribute is not critical for this lab. It was
used in original training playgrounds for basic testing purposes. The other
attributes (Subscription Type and Number of Accounts) are what the
decomposition relationship actually cares about.
5. Click the hyperlink for the Spotify RFS with the Add action. This reveals the technical
inventory JSON blob of the product that was eventually assetized for the account just
created. In short, technical orders result in technical inventory. Inventory Items are
the representation of this fact.
6. Return to the tab with the decomposed order and click View Orchestration Plan. (At
last… the moment of truth!)
NOTE:
Your swimlanes and tasks may display in a slightly different order, according to
the Show Order set earlier. If you did not complete the house cleaning task at
the end of the Push Event exercise, an additional swimlane for the Test Push
VAS will be in your results.
Notice that because the subscription type was “Free”, the Billing Deactivate was executed,
and the Billing Activate was skipped. Clearly, each swimlane could have additional tasks and
dependencies. For example, for a new Spotify Free customer, the SMS swimlane could be
named generically as a Messaging swimlane, and in addition to the SMS welcome message
a promotional email could be sent to encourage an upgrade to Spotify Premium. The
options are endless really.
BEST PRACTICE:
Recall the Orders tab includes an Account Name column for easy navigation.
NOTE:
To implement MACD, Salesforce Industries uses future dated orders (FDOs).
When you think of changing or disconnecting an order, typically the desired
action needs to take place in the future. For example, a change to increase
throughput starting tomorrow, or discontinuing a service after the current
billing cycle ends in two weeks, etc.
1. Select Spotify from the Service Asset Management page on the account and click
Change to Order.
2. Set a legal date and time on the Future Dated Order (FDO), then click Next.
3. Configure the order. Change the subscription type from Free to Premium.
(Optionally, change the Install Account Name too. Feel free to use this field for notes
if you like. Later you should see the attribute value change to whatever you enter.)
Notice the action is Modify (not Add). The technical attributes have mapped through and
assetization has already completed, as indicated by the Inventory Item on the fulfillment
request line item. (If assetization has not completed, feel free to wait a few seconds and
refresh your browser.)
5. (Optional) Click the Orders tab. You should see the original order, and the changed
(future dated) order.
TIP:
Future dated orders are not given names by the system. If you are running a
lot of tests, you can edit the order and add a descriptive name. For example,
“Upgraded from Spotify Free to Spotify Premium”.
6. Click View Orchestration Plan. Look over the plan. Is there anything different than
the plan for the original add order?
● Activate Billing is executed (Deactivate is skipped, hence the dark gray color)
7. Look at the plan again. Based on what was executed, what do you expect to see
when you check the service assets on the account again? Look at the Service Assets
for the account you changed the order for.
There is a single Spotify asset, with attributes that reflect changes to the order (Premium,
and Joe Abrams esquire… making up names and titles can be fun. ;-)
Congratulations! You’ve stepped through a MACD change order. Sir Alan Abrams esquire is
proud of you.
Goal
● Step through the design process for a MACD disconnect
● Configure order orchestration to support MACD for disconnect actions
● Perform end to end tests of a service disconnect
Tasks
1. Review the MACD-1:1 Decomposition Model (Logical Orchestration View)
2. Create the orchestration plan definitions
3. Add a disconnect action to the assetization scenario
4. Configure the end-to-end (E2E) swimlane for the disconnect
5. Configure the spotify disconnect SMS swimlane
6. Configure the spotify disconnect billing swimlane
7. Configure the spotify disconnect provision swimlane
8. Configure orchestration dependency definitions for the disconnect
9. Test the disconnect
Time: 30 mins
What is a Disconnect?
The “D” in MACD stands for Disconnect. However, some use the term “Delete” or
“Discontinue” instead. A disconnect is tied to the action in an orchestration scenario.
NOTE:
This exercise requires the completion of an earlier MACD exercise (Intro to
MACD Orders with 1:1 Decomposition).
1. View the diagram below that shows a logical view for the Disconnect action.
If an SMS cancel message is confirmed, then the disconnect continues. That is, tasks
for billing, provisioning, SMS messaging, and finally assetization. This time,
assetization is dependent solely upon the completion of the billing task.
NOTE:
The diagram above is actually part of the earlier logical orchestration diagram
that included Add and Change actions. They are split out in order to focus on
the action tied to the current exercise and to allow for a larger display.
TIP:
Use the Save & New option to quickly loop through creating new plan
definitions. (Several other orchestration assets allow for this option as well. A
handy time saver when you need to create several.)
Note the absence of a new assetization swimlane for a disconnect operation. The
assetization swimlane created earlier can be reused. It is suitable for add, modify and
disconnect actions.
Also, note while configuring the swimlanes below, no conditions are needed. That is
because the disconnect action itself is enough with respect to order fulfillment of a
disconnected music service.
Previously, you created and configured the Spotify Assetization scenario. However, the
Action was set to add and modify only. For disconnects to work, the disconnect action
needs to be added.
1. Navigate to the Spotify Assetize Orchestration Plan Definition, then open the
Spotify Assetize Scenario in edit mode.
3. Click Save.
Now the Assetization swimlane with the assetization auto-task should work for Spotify
disconnect actions as well.
2. Create a new Orchestration Scenario for Spotify Disconnect E2E. Enter the
following information:
Action Disconnect
Recall that the default action is Add. Be sure to remove the Add action and include the
Disconnect action in the scenario. No conditions are needed.
3. Click Save.
Each time there is a change order on the Spotify asset for an account, and a delete is
configured and then the FDO is decomposed - the Spotify Disconnect E2E Scenario will
trigger the generation and execution of a new orchestration plan with an E2E swimlane,
based on the Disconnect line item action.
1. For the Spotify Disconnect SMS swimlane, create two new Milestone tasks. Name
them Spotify Disconnect SMS Cancel Confirmation and Spotify
Disconnect SMS Farewell. Set the Scope to Global.
2. Create a new Orchestration Scenario for Spotify Disconnect SMS. Enter the
following information.
Action Disconnect
Action Disconnect
1. For the Spotify Disconnect Provision swimlane, create a new Milestone task. Name
it Spotify Disconnect Provision Decommission. Set the Scope to Global.
Action Disconnect
1. For the Spotify Disconnect E2E plan, create a dependency for the Spotify
Disconnect End task upon the Spotify Assetize task.
Just prior to completing the plan you want assetization to take place.
2. For the Spotify Disconnect SMS plan, create a dependency for the Spotify
Disconnect SMS Cancel Confirmation task upon the Spotify Disconnect Start task.
3. Also for the Spotify Disconnect SMS plan, create a dependency for the Spotify
Disconnect SMS Farewell task upon the Spotify Disconnect SMS Cancel
Confirmation task
4. For the Spotify Disconnect Billing plan, create a dependency for the Spotify
Disconnect Billing Deactivate task upon the Spotify Disconnect SMS Cancel
Confirmation task.
5. For the Spotify Disconnect Provision plan, create a dependency for the Spotify
Disconnect Provision Decommission task upon the Spotify Disconnect SMS Cancel
Confirmation task.
6. For the Spotify Assetize plan, create a dependency for the Spotify Assetize task
upon the Spotify Disconnect Billing Deactivate task.
3. Confirm that the orchestration plan completes ok, including assetization. (This may
take a few seconds. Recall you can check that assetization completes in the
orchestration plan, as well as the Inventory Item update on the decomposed
fulfillment request line.)
5. Select Delete from the drop-down (rather than Configure as you did earlier).
6. Confirm deletion in the Delete Item dialog. Notice the Action changes from Existing
to Disconnect for the Spotify line item in the cart. (This may take 5-10 seconds or
so.)
Notice the Disconnect action for both the commercial and technical products. Make sure
that assetization has completed. (Assetization is evident when there is an Inventory Item
hyperlink on the decomposed technical product.)
8. Click View Orchestration Plan. It should look similar to what was whiteboarded
earlier. (However, your swimlane order may differ slightly.)
Once a service disconnect has been confirmed via SMS, disconnect operations for billing
and provisioning execute in parallel, along with an SMS farewell message. Assetization takes
place once the billing disconnect completes.
If your orchestration plan does not look similar to the one above, attempt to troubleshoot
why and resolve the issue. Dependencies are easy to get confused and are often the cause
of undesired results in the orchestration plan.
TIP:
The Print button can be used to print an orchestration plan to an attached
printer or save it as a PDF file.
Goal
● Configure order orchestration to support MACD with a one-to-many (1:M)
decomposition model
● Perform end to end tests of MACD
● Better explain assetization process and its impact on storing assets and inventory
items
Tasks
1. Review the whiteboards and post-it notes
2. View the product model
3. Review the pre-built orchestration assets
4. Create orchestration plan definitions
5. Configure the add new customer swimlane for shipping
6. Configure the disconnect customer swimlane for shipping
7. Create orchestration dependency definitions for E2E tasks
8. Create orchestration dependency definitions for shipping tasks
9. Create orchestration dependency definitions for the disconnect
10. Add a new order
11. Change an order
12. Disconnect an order
Time: 60 mins
1. Greg skims the post-it notes on the whiteboard again. A helpful reminder of a few
things to keep in mind as he plans out the Streaming TV offering. He adds another
note to the mix:
This is more of a guideline than a strict rule, but he wants to keep it in mind as he continues
to design and test MACD disconnects.
1. Look at the product model diagram above, then use the Vlocity Product Console to
familiarize yourself with it. (The model shows a design-time one-to-many
decomposition model with conditions based on the download speed technical
attribute that you will use to decompose, orchestrate, and test for MACD actions.)
2. Use the Products tab to view the decomposition relationships. Notice the following:
3. Next, Greg diagrams the logical view for the Streaming TV Service. As he
contemplates the product and decomposition models, the actions that need
supporting (Add, Modify, Disconnect), and his latest post-it note… something dawns
on him. He asks his team members “What should the swimlane for the Modify
action look like? What type of orchestration scenario is needed?” Review the
diagram below. With a hunch and his latest post-it note in mind, notice Greg may
have asked a trick question of his team.
NOTE:
In the interest of time and lack of repetition, this exercise assumes
provisioning is already completed and hence is not included in orchestration.
Not having to build out another swimlane for shipping when a customer changes their
order is rather nice. Almost like getting a free cup of coffee after your local coffee shop
punches your card 10 times. Buy 10, and the next one is on them. Sweet.
The end-to-end swimlane will handle all but the shipping related tasks. You will build out
orchestration for shipping product to the customer next.
Create three new Milestone tasks. Set their Scope to Global, and name them:
2. With the shipping tasks created, next, you will need to add some conditions.
Configure Ship STB Bronze (Indiana) by adding a new single condition with the
following information:
Operator =
Value 7Mbps
Action Add
4. Configure Ship STB Silver (SoCal) by adding a new single condition with the
following information:
Operator =
Value 12Mbps
Action Add
6. Configure Ship STB Gold (NorCal) by adding two conditions. (Tip: Remember to use
OR in the No Condition dropdown, then configure two expressions.) For the first
condition use the following information:
Operator =
Value 20Mbps
Operator =
Value 40Mbps
Remember to set the condition type to OR, then click Save Conditions when ready.
Action Add
No conditions are needed for the scenario. There are three tasks (one for each
service level) and three scenarios now.
2. Create a new Milestone task, set the scope to Global, and name it Disconnect
STB Ship Return Label and Box. No conditions are needed. (No
dependencies are needed either. The scenarios below should trigger the disconnect
swimlane based on the action for the given technical products.)
Action Disconnect
No conditions are needed for the scenario. Remember to remove the default Add
action, and add the needed Disconnect action.
Action Disconnect
Action Disconnect
No conditions are needed for the scenario. You have configured three disconnect
scenarios.
TIP:
Recall that it’s considered best practice to configure dependencies last. You
could however still create a new order, configure it, and test decomposition
and orchestration before configuring dependencies. Essentially, a quick look
to make sure decomposition is triggering swimlanes correctly. However, all
tasks within swimlanes will execute in parallel until dependencies are added.
For all dependencies, set the Scope to Global, and the Dependency Type to Depends On.
NOTE:
Your training playground may already have the dependencies below
configured for you. If so, simply confirm proper configuration. If you want a
visual of the dependencies, feel free to look at the orchestration plans shown
in Task 10, 11, and 12. The segments between tasks are the dependencies
needed to implement Add, Change, and Disconnect of an order.
1. For the Streaming TV E2E plan, create a dependency for the Streaming TV E2E End
task. Just prior to completing you want assetization to take place.
Continue to create or confirm dependencies for the other Streaming TV E2E tasks.
2. Create a dependency for the Streaming TV E2E Assetize task. Use the following
information:
3. Create four dependencies for the Streaming TV E2E Update Billing task. The first
three are for shipping out the correct STB (Bronze, Silver or Gold respectively):
Almost done! One more dependency is needed for disconnects that require
shipping out a return label and box. (Apparently, Infiwave wants its equipment
back.)
Dependency Item Definition Disconnect STB Ship Return Label and Box
1. For the Streaming TV Shipping New Customer swimlane, set dependencies for
shipping out the Set Top Boxes (STBs) from the correct warehouses. First, for the
Ship STB Bronze (Indiana) use the following information:
2. Select Configure Order from the Power Launcher and add Streaming TV Service to
the cart.
3. Use the Configure option from the dropdown to set the following attributes.
Note that based on the Download Speed attribute value (7Mbps), Streaming TV Service
decomposes to TV Bronze RFS. Further, the Inventory Item hyperlink means assetization has
completed. (Waiting a few seconds and refreshing your browser may be needed.) If your
name is Jason Blob, or you just enjoy looking at a big JSON blob, click the hyperlink and
look over the technical inventory for a minute. This JSON is used for MACD orders. (You will
see more on this later in the lab.)
Notice the E2E and shipping swimlanes. Silver and Gold STB’s will not be shipped (they are
skipped), and the Bronze is shipped from the Indiana warehouse. Once the downstream
system for shipping bronze STBs returns a success, the billing system is updated, the order
assetized, and the plan execution completes. That is a slick streaming TV service! Greg is
ready to binge watch that new series everybody has been talking about.
6. Confirm that the Service Assets for the account is correct. (That is, Evan Evans has a
Streaming TV asset, configured for 7Mbps Download Speed, etc.)
Unfortunately, Evan Evans went a bit overboard rough housing with his kids, Saint Bernard
dog, Siamese cat, pet canary, and albino hamster. Knocking over his SD TV did not end well.
However, he is looking forward to his new HD TV. It’s time to upgrade his broadband
package to take full advantage of the new TV’s extra features and quality viewing.
1. Select the Streaming TV Service from Evan Evans’ Service Assets and click Change
to Order.
2. Set a legal date and time on the Future Dated Order (FDO), then click Next.
3. Click Configure from the dropdown menu. Change the Download Speed to
12Mbps, and the Upload Speed to 2Mbps.
Note that the decomposition results in two FRLs: A disconnect of the old bronze TV service,
and an add for a new Silver TV service. Apparently, the guideline Greg wrote down earlier on
a post-it note proved to be true. When IOM decomposes the MACD order in-memory, it
builds out a decision tree and compares the “as is” inventory items (the Inventory Item
JSON) with the “as-requested” decomposition. From this IOM generates the fulfillment
request lines (FRLs) and their actions. (Disconnect and Add in this example.)
5. Click View Orchestration Plan. Greg hopes the decomposition triggers orchestration
with downstream systems to ship out a Silver STB, and a return label and box to ship
the old bronze STB back to Infiwave. Fingers crossed…
Notice an additional swimlane is triggered. The Disconnect action triggers the disconnect
swimlane which assures that a return label and box is sent to the customer so the old
(bronze) STB can be shipped back. The shipping swimlane skips the bronze and gold STBs
and ships out the silver STB. (Again, based on the decomposition of the changed order with
a download speed of 12Mbps.) Once the disconnect and shipping downstream systems
return a success and the tasks change to a completed status, the remainder of the E2E
swimlane completes without error.
6. Confirm that the Services Assets for the account is correct. (That is, Evan Evans has a
Streaming TV asset, configured for 12Mbps Download Speed, 2 Mbps Upload
Speed.)
1. Select the Streaming TV Service from Evan Evans’ Service Assets and click Change
to Order.
2. Set a legal date and time on the Future Dated Order (FDO), then click Next.
3. Click Delete from the dropdown menu. Confirm the deletion in the dialog box. Wait
a few seconds to make sure the CPQ line-item Action changes from Existing to
Disconnect.
Notice the disconnect swimlane sends out an STB return label and box. No other shipping is
needed or expected, so the remainder of the E2E swimlane executes and completes
(update billing and assetization tasks).
6. Confirm that the Services Assets for the account are correct. (That is, Evan Evans has
three Streaming TV assets: one for himself, one for his dog, and one for his cat.
Wrong! Evan’s account should have no Service Assets now. Just making sure you are
still alert and tracking. ☺)
Greg is feeling pretty good and thinks it’s about time to plan his next vacation.
Goal
● Review the product and orchestration models along with what is used to support
order cancellation
● Describe order status related changes in Industries CPQ and IOM for order
cancellation
● Configure orchestration for order cancellation
● Create rollback plans and associate them with standard orchestration plans
● Create and test Point of No Return (PONR)
● Perform end to end tests of order cancellation
Tasks
1. View the Product and Orchestration Models
2. Create the Orchestration Plan Definitions
3. Cancel an In-flight Order
4. Test Point Of No Return (PONR)
Time: 45 mins
The use case for canceling in-flight orders is pretty straightforward. Similar to just about
everything in life, things change. In this case, a change may entail canceling an order
completely. It can be a bit tricky if part of the order has been fulfilled, and part of it has not
been fulfilled.
NOTE:
In the interest of time, and in order to focus on new concepts pertaining to
order cancellation, part of the training playground has been configured for
you. Further, other aspects of the order cancellation labs have been simplified.
For example, simple swimlanes, with just a few tasks that are mostly
milestones or manual tasks, and decomposition relationships that are not
concerned with mapping technical attributes. Decomposition details are not
the focus of order cancellation.
The product model in the Shared Catalog, along with the decomposition relationship and
orchestration configuration used for the first in-flight order cancellation are all quite simple.
1. Look over the high-level product model, and the orchestration model.
NOTE:
OC is an abbreviation for “Order Cancel” in this lab exercise. Product model
assets are created for you. You will create the orchestration assets as part of
the hands-on lab exercise.
Key takeaways from the end to end diagram shown above are:
● Mobile Data Plan Offer (commercial product) decomposes to the OC Activation RFS
(technical product).
● An Add action for the OC Activation RFS triggers the dynamic generation and
execution of the OC Provision Mobile orchestration plan.
● If (and only if) the order is canceled does the OC Rollback Provision Mobile swimlane
get executed.
● The trigger for executing a rollback plan is not an Orchestration Scenario. Rather, it is
set in the Rollback Plan Definition of a task. (As shown by the text callouts in the
diagram. More on this later.)
2. Open up the Vlocity Product Console. View and confirm the product structure for
the Mobile Data Plan Offer and its children.
3. Similarly, confirm the OC Activation RFS technical product, and that there is a basic
decomposition relationship (Mobile Data Plan -> Activation Spec) between the two
products in the Shared Catalog.
NOTE:
Although the decomposition relationship is very basic and does not even
include technical attributes, don’t lose sight of the crucial fact that the
decomposition process is critical in starting and passing key data to the
orchestration process. Order cancellation requires proper configuration and
use of the Shared Catalog, Industries CPQ, and Order Management. The entire
cancellation process requires that all three work in concert with each other.
NOTE:
Orchestration scopes allow you to control how the orchestration execution
engine resolves orchestration dependencies among orchestration items at
run-time. The default scope for an Orchestration Plan Definition is Global. The
default scope for an Orchestration Item Definition is Swimlane. The scope
settings do not impact the order cancellation labs and you can leave their
default values.
Show Order 1
As usual, when assets are created or modified in the steps here, don’t forget to click Save
when ready.
NOTE:
If you do not see the Technical Order Reviews queue as an entry in the
Manual Queue field’s drop-down list, simply enter tech then the Enter key,
and select it from the modal window.
This manual task is not functional with respect to provisioning mobile phones but will be
used to pause the progression of the orchestration plan for testing purposes.
4. Click OC Pause Provision Mobile. Switch to the Related tab and create a
dependency.
5. Go back to the OC Provision Mobile orchestration plan definition and create a new
Orchestration Scenario.
This scenario should trigger the new swimlane whenever decomposition results in an Add
action for the OC Activation RFS (which is the technical product the Mobile Data Plan Offer
decomposes to). With the orchestration plan in place for provisioning a mobile, it’s time to
create and configure what to do when an order for provisioning a mobile is canceled.
TIPS:
Consider using a naming convention such as including RB or ROLLBACK in the
name of your rollback swimlanes. It can be helpful to set the Show Order
value such that rollbacks are shown first, or last. That is, the value helps group
them first or last in the display of the executing orchestration plan.
Show Order 1
Clearly, there could be additional tasks within the rollback, but for now, let’s keep things
simple. (Additional tasks and dependencies are set up the exact same way you set them up
in previous lab exercises.) Now that the orchestration plan and the rollback plan are both
defined, the two must be associated. Remember, it is not an Orchestration Scenario that
triggers the rollback plan, it is the setting of the Rollback Plan Definition in a task (or tasks)
in the orchestration plan.
8. Go back to the OC Provision Mobile orchestration plan definition. Edit the OC Start
Provision Mobile task and set the Rollback Plan Definition to OC ROLLBACK
Provision Mobile.
Only if an order is canceled will the association between the orchestration plan and the
rollback plan defined here be used.
With order cancellation fully configured, it’s time to use the Cart to test things out. First, you
will place a new order, for a Mobile Data Plan Offer, and add 5G to the Cart.
NOTE:
There are extra steps in this Task to help with your understanding of how order
cancellation works. All steps are not required for cancellation, and the user
experience can be streamlined once understood or for users who do not need
to know details such as order status.
2. Click Save. If you end up testing several orders, simply increment the number in the
Order Name each time.
3. Select Configure Order from the Power Launcher and add Mobile Data Plan Offer
to the cart.
4. Click Add to Cart for the 5G Data Plan. Leave a browser tab with the order in it. (You
will return to it later.)
The decomposition is as simple as it gets. In fact, technical attributes have been omitted
from configuration so there are less distractions. The key is the decomposition of the
commercial product Mobile Data Plan Offer results in an Add of the technical product OC
Activation RFS. The Orchestration Scenario will ensure the execution of the OC Provision
Mobile you just created, based on the action (Add) and the product (OC Activation RFS).
Nothing exciting yet. The start Milestone has completed, and the Manual Task has paused
execution of the plan, as it waits for manual intervention. Leave a browser tab open with
this orchestration plan executing in it. (You will return to it later.)
7. (Optional) If you want to confirm that the rollback configuration will not alter the
standard flow of an order that is not canceled, follow these simple steps:
8. Return to the tab that has the order open in the cart. This view has not reflected the
order decomposition you just ran. Notice the following:
Reload the page. The updated page reflects the decomposition you just ran.
The Cancel option in the dropdown is conditional. When CPQ submits an order to
Industries Order Management for decomposition the order status changes from Ready to
Submit to In Progress and the Cancel action is exposed in the dropdown action menu.
TIPS:
Some may find it helpful to keep a browser open with the Orders tab in it,
view all orders, and pin it. Clicking the Order Number column header toggles
the sort order (ascending/descending).
8. Select the Cancel option in the dropdown. (Order submission from CPQ to IOM can
take a few seconds.)
Notice the task that was in a Ready state (not completed state) has been Frozen. Hover over
the OC Pause Provision Mobile task to confirm the Frozen state. (Note: It may take a few
seconds for the plan to update. You can refresh your browser to speed things up.) The plan’s
State (upper left of the Details tab) is also Frozen.
10. Return to the browser tab with the Cart, where the Order Submission Results dialog
is waiting. Click Next.
11. Return to the Orchestration Plan tab again. (Wait a few seconds or refresh the page
if it does not look like the following screenshot.)
● OC Start Provision Mobile was Completed but is Cancelled now. (Black color, “X” in
the task header, and the hover text confirms the Cancelled state.)
● OC Pause Provision Mobile was paused but is Discarded now. (Brown color, garbage
can icon in the task header, and hover text confirms the Discarded state.)
● The OC ROLLBACK Provision Mobile swimlane has been triggered and it’s one and
only task completed. (Of course, a more elaborate rollback plan could execute
additional “undo” tasks.)
● Dependencies for the OC Unprovision Mobile task in the rollback swimlane were
automatically generated by the orchestration engine. (Recall that you did not create
dependencies at design-time.)
● The State field in the Details tab of the executing plan is Completed. (This may take
a little while, or a browser refresh to confirm.)
12. Navigate to the Orders tab and view All Orders. Initially, when the order cancel was
requested but not carried out, the Orders tab was similar to:
The Orders tab can be configured to display the Salesforce Status, Order Status, as well as
the Superseded Order fields. By now you should be familiar with the Status and Order
Status. Also, notice the following:
● The original order and the supplemental order generated by CPQ have the same
Order Name
● The supplemental order’s Superseded Order field associates it with the original
in-flight order (the order that was canceled)
Once the order is canceled, the Orders tab transitions to the following:
The original order has been superseded and the supplemental order has been canceled.
13. Open the original order and select Configure Order from the Power Launcher to
view the order from the cart. Notice that the order status is Superseded there as
well. The original order is read-only and therefore cannot be changed.
14. From the Orders tab, click the order number for the supplemental order, then select
View Decomposition from the Power Launcher.
Supplemental orders are automatically decomposed after CPQ generates them based on
the original order. Notice the Supplemental Action is Cancel now. (The original order
decomposition was Add for each line item action.)
The order status is CANCELLED. (This confirms the Order Status seen earlier from the
Orders tab. It can be viewed from either location in the user interface.) Notice the text for
the line items all have a line through them (strikethrough indicates the cancel).
2. Click the edit icon for Point Of No Return. Check the box and then click Save.
3. Create a new order or clone an existing order. Name it OC Mobile Data Plan
Offer – Test PONR.
NOTE:
If you clone an order, remember to change the Name and set the Status to
Draft before saving it.
4. Select Configure Order from the Power Launcher and add Mobile Data Plan Offer
to the cart, with the 5G Data Plan.
6. Click View Orchestration Plan. The Start task has completed, and the Pause task is
in a Ready state.
Tasks that have been marked PONR include a prohibition (red arrow/slash) icon so they are
easily identifiable at a glance.
7. Return to the cart for the order and click Cancel from the dropdown. (If you do not
see Cancel try refreshing your browser first.)
TIPS:
After you cancel the order, if you quickly refresh your browser a few times
while viewing the orchestration plan you should see OC Pause Provision
Mobile task change to Frozen then back to Ready. (Depending on exact timing
of the refreshes in relation to the pre-validation check.)
Order Management has immediately told CPQ that the order cannot be canceled. Why? A
task (OC Start Provision Mobile) in the executing orchestration plan (OC Provision Mobile)
with PONR set has already completed.
8. Click Next.
Since the PONR setting caused IOM to reject the order cancellation request, the original
Order Status has not been Superseded (it remains In Progress), and the supplemental
Order Status is Rejected.
10. Edit the OC Start Provision Mobile task in the OC Provision Mobile plan. Uncheck
the Point Of No Return and click Save. (Turn PONR off in case you end up creating
and testing additional orders.)
Goal
● Step through the design and test process for a more complex order cancellation
scenario
● How to configure and use Rollback Groups
● How to configure and use “Smart Freeze” cancel behavior on a running task
Tasks
1. View Existing Product and Orchestration Models
2. View the Order Cancel Configuration
3. Cancel an In-flight Order (mid-way through fulfillment)
4. Cancel an In-flight Order (nearly fulfilled)
5. Create Rollback Groups
6. Test Rollback Groups
7. Test Smart Freeze on a Running Task (optional)
Time: 1 hr 15 mins
Where to start?
Greg needs a refresher before considering all the issues for configuring and testing order
cancellations for Infiwave FLEX Streaming Service and FLEX DSL Service. Thankfully, he
recalls he can place a test order, decompose it, and simply click the Print button to use the
completed orchestration plan for his planning meeting with product marketing, product
management, and the business analyst. A few screenshots and the printout will work way
better than his messy whiteboard diagrams!
The first Infiwave product offering that needs to support order cancellation is their FLEX
services.
3. Click Add to Cart for both the FLEX Streaming Service and FLEX DSL Service
products.
5. Click the link icon for both commercial products to highlight the decomposition for
each.
NOTE:
Partial decomposition results are shown to avoid crowding the page.
6. Now click the link icon for the ADSL2 CFS technical product.
As expected, several swimlanes with multiple tasks and different task types are executed as
part of the orchestration plan. Take a moment to peruse the plan. Time and interest
permitting, view the various products, decomposition relationships, orchestration plans,
and orchestration scenarios that trigger those plans. Don’t forget that segments joining
tasks are defined by dependencies.
Greg decides to progress the status of the orchestration plan, so he can get a complete view
of the fulfillment process for the FLEX products. He’ll use that as a discussion starter in the
upcoming planning meeting.
8. Right-click the Consumer Credit Check task and select View Record.
9. Click the hyperlink for the Manual Queue (Consumer Credit Check).
10. Click the entry’s checkbox then click the Complete button to complete the item in
the queue.
11. Return to the executing orchestration plan and complete the remaining Manual Task
to progress the plan along (Wire Copper Pair).
12. Change the state of the Push Events from Running and Pending to Completed as
well (Equipment Dispatched and Equipment Received tasks respectively).
The completed plan with no order cancellations should look similar to the above diagram.
Note that assetization may take a few seconds to complete. (That is, the last Create Assets
Auto Task.)
NOTE:
Normally, this lab task would step you through creating new rollback plans and
associating them with the appropriate orchestration plans. However, since you
have already learned how to create and configure them, in the interest of time
this lab task will confirm proper configuration before you test the order
cancellation process. Although you are not configuring anything in this Task,
try not to rush it. Take some time, as there is a lot going on with respect to
configuration of swimlanes, tasks, rollback plans, etc.
Notice the Rollback Plan Definition setting associates this task with the Rollback FLEX
Streaming plan for rollbacks. If an order is canceled that uses this Orchestration Item
Definition, the tasks in the Rollback FLEX Streaming orchestration plan will be triggered.
3. Click the Rollback FLEX Streaming hyperlink. This rollback orchestration plan has
just one task (Deactivate FLEX Streaming). Notice there is no Orchestration
Scenario. Again, orchestration scenarios are not used to trigger rollback swimlanes.
4. Open up the DSL Modem Delivery orchestration plan definition. This plan has three
tasks in it.
Again, notice the Rollback Plan Definition (Rollback Equipment Dispatch) associated with
this callout task. If an order is canceled that uses this Orchestration Item Definition, the
rollback plan shown above will be triggered.
6. Click the Rollback Equipment Dispatch hyperlink. This rollback orchestration plan
has just one task (Recover Equipment). Once again, notice there is no Orchestration
Scenario. Let’s continue to look at the rollback configuration already on your training
playground.
7. Open up the Copper Pair Fulfilment orchestration plan definition. There are two
tasks within the swimlane. (Design Copper Pair and Wire Copper Pair.)
8. Click the Design Copper Pair task. Notice the Rollback Plan Definition associated
with the task. It should be Rollback Copper Pair Design.
9. Click the Rollback Copper Pair Design hyperlink. This rollback orchestration plan has
just one task (Release Reserved Copper Pair).
11. This time click the Wire Copper Pair task. Notice the Rollback Plan Definition
associated with the task. It should be Rollback Copper Pair Wiring.
12. Click the Rollback Copper Pair Wiring hyperlink. This rollback orchestration plan has
just one task (Undo Wiring).
13. Lastly, look at the DSL Service Provisioning orchestration plan definition. Peruse the
UI following similar hyperlinks as earlier and notice the following structure:
Now that you have seen the orchestration plans involved, along with the rollback plans and
their tasks, if an order with FLEX services gets canceled, it’s time to test it out. Greg’s fingers
are crossed. (Are yours?)
You will create another order for FLEX services in order to test order cancellation for these
products.
1. Create a new order and add FLEX Streaming Service and FLEX DSL Service to the
cart again. Name the order OC FLEX Test.
TIPS:
Use the same order creation process as Task 1 earlier in this lab exercise.
3. Click View Orchestration Plan. The Orchestration plan should look familiar too.
4. Right-click the Consumer Credit Check task and select View Record.
6. Select the checkbox and click the Complete action to complete the Consumer
Credit Check manual task.
Notice that the orchestration plan is in progress, and has tasks in four different states:
● Completed (green)
● Pending (gray)
8. Return to the cart and select Cancel from the dropdown menu. CPQ submits the
order to Order Management.
If the Point of No Return (PONR) has not been violated, IOM pre-validates the cancel
request and works on freezing the orchestration plan.
9. Return to the executing orchestration plan in a different browser tab. The State is
Freezing and the plan looks like the following.
Notice that all uncompleted tasks that are not yet running are in a Frozen state. (In our case,
Ready, and Pending tasks, and the Push Event that is waiting and has not started Running
yet. By default, IOM does not freeze running tasks. That is why the first Push Event is not
frozen. If your plan does not show frozen tasks yet, wait a few seconds or refresh your
browser.)
11. Return to the orchestration plan and advance the first Push Event (Equipment
Dispatched) by changing the state to Completed. This will get the plan progressing
again.
12. View All Orders from the Orders tab. Notice the original order, and the CPQ
generated supplemental order with the same name. The Superseded Order field
contains the original in-flight order number. Again, this associates the supplemental
order with the original order it supersedes when the original order is canceled.
Depending on the timing and how fast the orchestration engine works, your Order Status
may be slightly different. (You could see Submitted, or even Cancelled if it is really working
fast or you took your time looking.)
13. View the original OC Flex Test order from the cart. Depending on timing and
browser refreshes, notice the status in the upper left. It will settle on SUPERSEDED,
which aligns with the Order Status in the Orders tab. Also notice that the order is
read-only and hence cannot be further configured or modified in the cart.
14. Return to the Orders tab, click the supplemental order, enter view and select View
Decomposition from the Power Launcher.
Supplemental orders are automatically decomposed after CPQ generates them based on
the original order. Notice the Supplemental Action is Cancel for each fulfillment request.
(The original order line item actions were Add only, with no supplemental actions.)
15. Now view the supplemental order from either the cart or the Orders tab again. By
now the status should be COMPLETE. (Hmmm, if the status is complete, then the
orchestration plan should have been completed as well.)
16. Return to the Orchestration Plan. Depending on timing, the State of the executing
orchestration plan (upper left of the Details tab) is In Progress or Completed.
Several things have changed from the last time you looked at the plan, however.
Wow…It worked! Let’s summarize the key points in relation to the orchestration plan above:
● Previously completed tasks have been canceled.
● The Push Event (Equipment Dispatched) that was Running but waiting on an event,
was also canceled.
● Tasks that were in a Pending state and successfully Frozen when the cancel request
was submitted from CPQ have been Discarded. Note that discarded tasks, even if set
up to trigger a rollback plan, do not trigger the rollback. Why? Nothing was done
originally, so there is nothing to “undo”. Note this includes the other Push Event
(Equipment Received) that was waiting for an event (while in a Pending state).
● Three rollback plans have been triggered. Each one has a single task within it, and
they have all completed. (The last three swimlanes in the orchestration plan
screenshot above.)
Earlier you identified five tasks in 4 rollback swimlanes that needed to be triggered if a Flex
order was canceled. Why did only three rollback swimlanes get executed in the
orchestration plan above? (The completed callouts in swimlanes named “ROLLBACK…”)
Recall that you canceled the order roughly mid-way through it. Tasks that have not been
completed yet should not be “undone”. Therefore, three rollback plans are part of the
orchestration plan, along with the tasks for “undoing” the FLEX services. Those tasks have
been completed successfully.
Let’s reiterate a subtle point by way of an example – If a task is in a pending state when the
order is canceled, even if a Rollback Plan Definition is configured it will not be triggered. The
Update Billing task was pending when the order was canceled, so a configured rollback plan
was not triggered. By design, orchestration does not “undo” something that was never
“done” in the first place.
Greg is feeling pretty good about how order cancellations are implemented and is ready to
reschedule his camp trip. Maybe he’ll even add another day to the trip. Nice. Where did he
put the graham crackers, marshmallows, and chocolate bars again?
1. Create a new order and add FLEX DSL Service and FLEX Streaming Service to the
cart again. Name the order OC Flex Test 2.
3. Click View Orchestration Plan. The Orchestration plan should look familiar too.
4. From top-to-bottom, left-to-right, advance each task so that it is Complete until you
get to the Billing Approval task. Leave Billing Approval’s status alone. All tasks should
be green, except Billing Approval (blue), and Create Assets (gray).
TIPS:
Truth be told, Greg added the last Manual Task as a way of pausing the
orchestration plan execution before the entire plan completes. A nice trick
when in dev and test mode. Sometimes he uses Push Events with Event
Conditions that evaluate to false for a similar purpose.
5. Return to the original order and select Cancel from the cart. Once the order is
submitted to IOM, click Next on the submission results dialog.
NOTE:
The orchestration plan below focuses on the rollback swimlanes. The rest of
the orchestration plan is similar to what you have seen previously.
Notice that this time all five rollback plans were triggered from each of the 5 tasks
configured to trigger a rollback plan. However, not all tasks within them are completed. The
Undo Wiring Manual Task is Ready, and the Deactivate DSLAM Port Callout is Pending. (It
cannot start execution yet, due to dependencies.) Before completing the plan, quickly
check a few more statuses.
7. Check the Order Status of the original order in the Orders tab. It should be
Superseded.
9. Return to the orchestration plan currently In Progress and change the state of Undo
Wiring to Completed. (All tasks in the plan will complete now. However, the State
may take a few seconds before it is marked Completed. Refresh your browser a few
times if need be.)
11. Check the supplemental Order Status again. It is Cancelled. (The Salesforce Status
changed from Draft to Activated as well.)
Greg is the man! Well, the undo man? He’ll have to work on a better nickname. The
Canceler? He’s not sure if that has a superhero or an Arnold Schwarzenegger action movie
overtone to it. Oh well. At least order cancellations are working.
● Dependencies between tasks are configured and behave the same way as well.
Rollback Groups do not affect the execution order of tasks in rollback plans. They do
affect the execution order of the rollback plans themselves though.
● A Cancel order request in concert with Rollback Plan Definition settings trigger the
execution of a rollback plan (not Orchestration Scenarios).
● Tasks within rollback plans that have the same string in the Rollback Group field are
part of the same Rollback Group. By changing this field, you can change the order of
execution of the rollback plans they trigger.
● By default, no tasks are in a Rollback Group. The field is null, and the order of
execution is the same as the original orchestration plan.
Greg’s plan is to create four new swimlanes for a rollback plan, with either 1, 2 or 3 tasks
each. That way, he can clear up whether or not the order of execution of tasks within a
rollback plan are affected by rollback groups or not. (There is some confusion amongst
team members on this one.) He decides to use a naming convention prefaced with “OC RG”
for Order Cancel Rollback Group. Then he’ll name each of the rollback plans starting with A,
B, C and D so the execution order is easy to spot as he runs a few tests. Lastly, the task name
convention includes “Undo #” (Undo 1, Undo 2, etc.).
Name OC RG ADSL
NOTE:
The underscore of “A” in ADSL above is simply to draw attention to the naming
convention used.
The Show Order for each swimlane created is incremented by one to make the
four rollback plans display near the top (if set from 1 to 4) or pushed near the
bottom (if set to 101 to 104). Either approach is fine.
2. Create three Orchestration Item Definitions within it (OC RG ADSL). Use the
following information for the first one.
Leave the rest of the fields blank, including the Rollback Group. You will set and test that
later.
Name OC RG Billing
Name OC RG DSL
With all the Orchestration Plan Definitions and the Orchestration Plan Items (tasks) for
rollback plans and rollback groups created, a few task dependencies need to be configured.
13. Click New to create a new dependency. Use the following information.
14. Click Save. The key fields should look like the following:
15. Open up OC RG ADSL Undo 2 and switch to the Related tab. Click New and use the
following information.
OC RG Billing only has two tasks, so there is only one more dependency to configure.
18. Click New to create a new dependency. Use the following information.
Next you will need to set the Rollback Plan Definitions in various tasks in order to trigger
execution of the new rollback plans.
NOTE:
If you lose sight of the bigger picture it’s easy to make a configuration error.
You must set the Rollback Plan Definition field within the correct tasks….
which are not the actual tasks you just configured. Rather, each task in a
regular orchestration plan that requires “undo” tasks when an order is
canceled. Those are the tasks that need to be configured to trigger rollback
plan execution.
19. Navigate to Orchestration Plan Definition > ADSL2 E2E Fulfilment > Test DSL
Service. Set Rollback Plan Definition to OC RG ADSL. Notice that a single task, such
as Test DSL Service, can trigger a rollback plan that contains one or more tasks. In
our example, OC RG ADSL has three “undo” tasks.
20. Navigate to Orchestration Plan Definition > FLEX Service Orchestration > Update
Billing. Set Rollback Plan Definition to OC RG Billing. Recall that OC RG Billing has
two “undo” tasks.
21. Navigate to Orchestration Plan Definition > DSL Service Provisioning > Activate
DSLAM. Set Rollback Plan Definition to OC RG Copper Pair. (Note: Due to an earlier
Task, you will have to delete the current setting: Rollback DSLAM Activation. This is
fine and will not impact the remainder of this lab.)
22. Navigate to Orchestration Plan Definition > DSL Service Provisioning > Design
Local Connectivity. Set Rollback Plan Definition to OC RG DSL.
Now four tasks in orchestration plans that require one or more tasks to be “undone” when
an in-flight order is canceled are configured and ready to be tested.
1. Create a new order and add FLEX DSL Service and FLEX Streaming Service to the
cart again. Name the order OC Flex RB Test. (Use similar configuration as
previous test orders with respect to account, price list, etc.)
3. Click View Orchestration Plan. The Orchestration plan should look familiar too.
5. Return to the original order and click Cancel from the cart. Click Next from the
Order Submission Results dialog.
7. Complete the Undo Wiring task in the Rollback Copper Pair Wiring swimlane. (This
is not necessary for the lab, however completed (green) tasks simply look better!)
Note that without any defined Rollback Groups, the left-to-right order for the tasks within
the four rollback plans executed in D-C-A-B order. The tasks within the swimlanes
themselves progress sequentially (1, 2, …) Next you will define a Rollback Group for both
the A and B tasks and test it on a similar order.
9. Navigate to Orchestration Plan Definitions > ADSL2 E2E Fulfilment > Test DSL
Service. Set the Rollback Group to ReverseAB and click Save.
NOTE:
The Rollback Group takes a string that you enter. It is not a menu or picklist.
Orchestration Item Definitions that have the exact same string in the Rollback
Group field are part of the same Rollback Group. The Rollback Group for all
tasks is null by default, hence no tasks are part of a Rollback Group until the
field is explicitly set.
10. Navigate to Orchestration Plan Definitions > FLEX Service Orchestration > Update
Billing. Set the Rollback Group to ReverseAB and click Save.
With the Rollback Group defined, you are ready to test it again.
11. Create a new order and add FLEX DSL Service and FLEX Streaming Service to the
Cart again. Name the order OC Flex RB Group Test. (Use similar configuration
as previous test orders with respect to account, price list, etc.) Once again,
decompose the order and view the orchestration plan. Advance the state of each
task to Completed until the Billing Approval Manual Task is Ready.
12. Return to the cart and click Cancel. Click Next from the Order Submission Results
dialog.
14. Complete the Undo Wiring task in the Rollback Copper Pair Wiring swimlane.
(Again, this is not mandatory, but does allow plan execution to continue and color
the completed task green.)
15. View the four OC RG* swimlanes in the orchestration plan again.
The execution order for the OC RG tasks has indeed changed. (A and B swimlanes have
reversed.) The “undo” tasks within the swimlanes have not changed order.
● The tasks within the rollback swimlanes are still sequential: 1-2-3 and 1-2
NOTE:
The four OC RG* swimlanes may not display in the exact sequence according
to their Show Order setting. If they are not adjacent to each as shown above,
the important thing to check is the left-to-right execution order of the tasks
within their respective lanes. (D-C-B-A above.)
Time and interest permitting, configure additional Rollback Group settings and test orders
to see how execution order is impacted.
Recall that the first thing an order cancellation request does is a pre-validation step,
whereby all tasks in a plan are checked to see if the point of no return has been reached.
Based on PONR and the task status, IOM attempts to freeze the plan. Usually, the majority
of tasks order cancellation impacts are tasks that have already been completed. However, a
running task is easily overlooked and may lead to confusion if not properly understood.
By default, when IOM attempts to freeze tasks in an executing plan, if the task is already
running it is allowed to finish. (The task is not frozen.) Setting a task’s Cancel/Amend
Behavior field to Smart Freeze allows the running task to be frozen. Although this behavior is
configurable for any type of task, it is more common for long running tasks like a push event
or callout.
In the remainder of this exercise, you will test the same order cancel procedure, first
without Smart Freeze configured, then with Smart Freeze configured.
1. Navigate to the Orchestration Plan Definitions tab and select DSL Modem Delivery.
This swimlane has three tasks in it. Two are push events. The ensemble of
screenshots below provide a reminder of run-time and design-time orchestration
assets in context.
For additional context of the original run-time orchestration plan, see the plans in Task 1 of
this lab exercise. (DSL Modem Delivery is the last of several swimlanes shown.)
3. Select Configure Order from the Power Launcher and add FLEX DSL Service to the
cart. (No need to add Flex Streaming Service this time for Smart Freeze testing.)
4. Click Decompose Order. View the decomposition results. They should look familiar.
6. Complete the Consumer Credit Check. Use either the Manual Queue user interface
or the Complete Item entry from the dropdown menu.
7. Return to the executing orchestration plan. Wait a few moments for the plan to
update and settle. Notice the state of tasks in the DSL Modem Delivery swimlane:
Leave a browser tab with the plan open. You will refresh it quickly after issuing a cancel
request in an attempt to catch the freeze plan progress. Remember, by default a running
task (such as Equipment Dispatched) should not be frozen if the order is canceled. It should
be permitted to run to completion on its own. (Such as an external system updating an
order attribute, or custom Apex code changing an attribute the push event constantly
evaluates, etc.)
8. Return to the cart for the Flex DSL Push test without Smart Freeze in-flight order.
(Remember to leave the associated orchestration plan in a browser tab as well!)
10. Switch to the browser tab running the orchestration plan. Refresh the browser.
Notice the running push event (Equipment Dispatched) is not frozen, the pending push
event (Equipment Received) is frozen, and the orchestration plan State is Freezing.
11. Return to the browser tab where you issued the order cancel request from. The
submission result is Waiting for plan to be frozen. Click Next.
12. Return to the orchestration plan. The Equipment Dispatched task could take a day, a
week, or longer… so it is permitted to run. The task must complete before the plan
advances further. You will do that next.
13. Select the running Equipment Dispatched task header and then click Complete
Item from the dropdown menu.
NOTE:
Normally custom Apex code might update the Push Event, or a fulfillment
system might update the order via a Callout. For simplicity sake, in this lab you
manually updated the task state with the UI.
14. Wait a few seconds and view the orchestration plan again. Once settled, it should
complete the order cancellation, and update the task states, plan State, and Order
Status along the way.
Now you will configure Smart Freeze and step through the same process for order
cancellation. The difference is subtle in the training playground, yet can be profound and
meet specific needs in a production environment.
15. Open up the Equipment Dispatched task in the DSL Modem Delivery orchestration
plan.
16. Click Smart Freeze in the Cancel/Amend Behaviour field and then click Save at the
bottom of the page.
18. Select Configure Order from the Power Launcher and add FLEX DSL Service to the
cart.
19. Click Decompose Order. View the decomposition results. They should look familiar.
20. Click View Orchestration Plan. This should look familiar too.
22. Return to the executing orchestration plan. Wait a few moments for the plan to
update and settle. Notice the state of tasks in the DSL Modem Delivery swimlane:
So far so good! Everything is identical to the previous order. What to pay attention to now is
the Equipment Dispatched task when you cancel the order and IOM attempts to freeze the
plan. This time, it will behave a little differently.
Leave a browser tab with the plan open. You will refresh it quickly after issuing a cancel
request in an attempt to catch the freeze plan in progress. Remember, by default a running
task (such as Equipment Dispatched) should not be frozen if the order is canceled.
However, with Smart Freeze set IOM will freeze it momentarily, then continue on with the
cancellation process.
NOTE:
System and network response time along with the timing of your browser
refresh can produce a slightly different experience.
23. Return to the cart for the Flex DSL Push test with Smart Freeze in-flight order.
(Remember to leave the associated orchestration plan in a browser tab as well!)
25. Quickly switch to the browser tab running the orchestration plan. Refresh the
browser.
Notice the running push event (Equipment Dispatched) is frozen this time, so is the overall
plan State. (This is a transient state this time however, as IOM continues the order
cancellation process because it doesn’t need to wait for Equipment Dispatched to
complete. Depending on timing and system performance, you may not capture the exact
same task states.)
26. Return to the orchestration plan. Watch how the plan updates without further
intervention this time.
Goal
● Design a multiple swimlane orchestration, complete with various Orchestration Item
Definition record types, and dependencies based on a subset of common real-world
departmental needs.
● Configure and test a staggered integration retry policy.
Tasks
1. Refresh several orchestration concepts (optional)
2. Review the finished orchestration plan
3. Build out the orchestration plan
4. Test the new orchestration plan
5. Configure a staggered integration retry policy
Time: 60 mins
Challenge exercises are optional. This Challenge exercise is split up into two sections.
1. More robust orchestration - Tasks 1-4. If you want more practice on the
foundations of orchestration, complete Tasks 1 through 4. If you are comfortable
with all the orchestration concepts and basic mechanics covered thus far, you can
skip to Task 5.
2. Configure a staggered retry policy - Task 5. The Fallout Management exercise did
not configure and test a staggered retry policy. Task 5 builds on the concepts covered
in Fallout Management but uses the staggered retry feature first introduced in the
Sprint 2022 release.
A little bit of repetition can help solidify concepts and best practices learned earlier. Here
are a few things to keep in mind as you complete this challenge:
● It is considered a best practice to use a modeling tool to build out your entire plan.
You’re in luck though! We have done that for you. (As evidenced by the next task.)
● Values for the Show Order determine where swimlanes are displayed.
● Consider basic naming conventions as you configure your challenge exercise. For
example, for orchestration scenarios:
Notice the plan identifies the swimlanes, the items within those swimlanes (including their
record types), and the dependencies.
Use the concepts learned earlier, and this Exercise Guide as needed to build the
orchestration plan.
1. When adding Manual Tasks, use the Credit Check Omniscript like you did previously.
NOTE:
Even though the logic of the Omniscript only makes sense in the Finance
swimlane, it’s the mechanics that are important, not what the script does
when invoked.
2. When adding Manual Tasks, create individual Manual Queues for each swimlane.
3. When adding the Create Assets auto-task, configure it similar to what was learned
earlier for product assetization.
4. When setting up the Callout, use the existing Training Mocker system as you did
earlier. Remember to create a new System Interface named Inventory System
though.
5. When adding the Orchestration Scenarios, use the Home Hub Modem as the
product.
NOTE:
Typically, Orchestration Scenarios trigger based on technical products that are
the result of a decomposed order. For example, the Orchestration Scenario
could use the Home Hub 2000 or 3000, which are the technical products the
Home Hub Modem decomposes to (based on the run time performance
setting of Good, Better or Best). However, this challenge is constructed so that
it is not dependent upon the successful completion of earlier exercises. This
could mean when you test your challenge later, decomposition could result
with no fulfillment requests. That will not impact the orchestration plan, which
is the focus of this challenge.
1. Place an order for a Home Hub Modem, decompose it, and look at the orchestration
plan. Did it work? Is it similar to the plan diagram shown earlier in Task 2? If so, well
done! If not, make modifications and test it again. Once it looks correct, continue
with the progression laid out below.
NOTE:
Not shown in the diagram is an additional Swimlane (Installation System) and
a Schedule Installation task. For simplicity, it was not included in the
Challenge or shown in the diagram. How did it get there? The Home Hub
Modem decomposes to the Installation System Resource, with the Installation
Type set to “Full” install. Recall from earlier that this triggers the Schedule
Installation callout in the Installation System swimlane. Basically, it’s a
by-product of configuration from earlier, but has no impact on the Challenge
and is OK to ignore.
2. Pretend you are the management team at Infiwave, and meet with other
department heads to approve the delivery plan for the order. (Note: Roleplaying and
talking out loud to yourself is taking it a bit too far and will not earn extra credit on
this challenge!)
3. Look at the manual queue you created for the Operations swimlane. Use the
Complete action to bypass the Credit Check Omniscript and move the orchestration
plan along.
4. As the Finance department looks things over, this time use the Pick Up action to run
the Credit Check Omniscript and approve of the customers good credit.
5. If the Training Mocker is up, running and the earlier configuration (remote site,
system interface) is correct, the Inventory swimlane should complete automatically.
(Reminder: A Milestone always completes immediately, it never fails or goes to a
pending state. Hence, the Verify PO should complete on its own.)
6. The department heads just met and signed off on the entire plan, so it’s ok to
signoff, assetize, and finish up your day! Look at the Operations queue again and
advance the orchestration process by using the Complete action. The orchestration
plan should complete and look similar to the one shown below.
TIP:
If you don’t see your order, recall the process for finding it in the JSON
response was covered earlier in this module.
1. Configure the Billing System URL so that future callouts will fail.
TIP:
Navigate to Systems > Billing, and append a “1” to the “.com” in the domain
name. Refer to the Reconfigure the System URL Task in the Fallout
Management exercise if you don’t recall how you did this earlier. (Earlier you
broke the domain of the Training_Mocker however.)
2. Create a new staggered retry policy. Enter Backoff Retries 1-2-4 for the name.
Set the staggered retry attempts to: 60,120,240 (With each callout failure it will
double the delay until the next attempt. This is known as an (exponential) backoff
algorithm. In the interest of time, you will limit the policy to just three delay intervals.
Since the comma separated values are in seconds, 60,120,240 equates to 1, 2 and 4
minutes.)
3. Associate the new staggered retry policy with the Update Billing task in the FLEX
Service Orchestration plan.
4. Create a new order and add FLEX DSL Service to the cart.
6. Advance the execution of the orchestration plan. Change all tasks that Update Billing
is dependent on to a Completed state so Update Billing can execute.
NOTE:
Update Billing should Fail, turn red, and include the circular arrow in the task
header as the callout retries according to the associated integration retry
policy.
7. Observe the Execution Log to observe the retry attempts. Do the failed attempts
back off as you expected?
TIP:
Initial releases of IOM required you to click on the Task header to drill-down
on the Details of the task, including the Execution Log. Now you can right-click
on the task and select View Record. Try it out if you never have!
The timing will vary somewhat, but from the initial callout attempt, then the three retries,
and finally the last failed callout about 8-9 minutes will elapse. An example Execution Log
with the staggered retries as defined earlier looks like this:
4/7/2022, 10:41 AM FATAL Orchestration Item is over the maximum retry limit.
4/7/2022, 10:39 AM FAILED Item is queued for pick up by retry job from 10:40:04
4/7/2022, 10:36 AM FAILED Item is queued for pick up by retry job from 10:37:40
4/7/2022, 10:34 AM FAILED Item is queued for pick up by retry job from 10:35:31
4/7/2022, 10:32 AM FAILED Item is queued for pick up by retry job from 10:33:31
8. Housekeeping task. If you plan to use your Training Playground for additional tests,
including callouts, etc. you will need to repair what you broke earlier in this
Challenge exercise. Specifically, change the Billing System URL to a legal domain
again. (Remove the “1” from the System URL, so it ends with “.com” not “.com1”.