Consume by customization: enabling safe process customization points

Overview

From the previous topics, we know that some kinds of enhancements will not fit the simple model of "automatic" or "opt-in". Sometimes, there will be more substantive changes that will require the customer to perform more involved customization in order to consume the new capability.

This topic actually attempts to "kill two birds with one stone" in a sense. It not only provides an example of feature consumed by customization; it also shows one technique for making the application itself inherently more customizable going forward without even requiring any kind of upgrade!

Applications are Not Customizable by Default

In order to encourage developers to carefully consider the potential for customization up front, all of the definitions you have been creating have used a setting called Application Scope by default. This means that they will be completely locked-down for customization purposes. This is often a good thing, because it means that:

As a developer, you have control over what happens with the application at run-time.
You will be able to safely modify any of your definitions when releasing an Update Package, so that your consumers don't need to worry about having their customization overwritten, or have the application suddenly stop working.

Of course, the downside of this is that the application has become somewhat less flexible. Essentially, the only kinds of customization that can happen now are:

Configuration / Settings types of changes (whether using the Settings Service or just by using Record-based configurations of your own)
Additive changes, such as creating new Records, new Views, new Rules, and so on.
Skinning / Branding of the color scheme.

One area that customers should have access to is the Business Process (in the case of this tutorial, this is represented mostly by the Order Lifecycle). One strategy here is to make this process completely Public Scoped and Customizable. This is a valid way to go, as long as you understand the implication of this decision.

As a developer, you can never change this process in a later version of the application, or if you do, be aware that your changes may be "hidden" by customization. You will also need to make sure there is nothing in the process that is essential for the integrity of the application. In the case of Order Lifecycle, since the behavior of the process is mostly about state changes and notifications, you might get away with this approach.
Another way of handling this is provide a new version of the process (such as Order Lifecycle v2), and instruct the customers on how to consume this. The downside of this is that the workspace becomes cluttered with different versions of the same process; also, it may make it difficult to know which processes rely on the interfaces of other processes.

Allowing Customization through Extension

There is actually another way of handling this, that allows some measure of control but still allows important customization to occur. In this approach, you build in anticipated customization points into your non-customizable process. To do this:

Identify an aspect of behavior that you would like to be completely customizable. Often these have to do with customer specific workflows (such as approvals), or integrations. It's best if this kind of behavior is "additive" to the essential functioning of the application.
Create a default, Public Scoped, Customizable stub process that represents this additive behavior.
Modify the master process so that it invokes the stub. Leave it as Application Scoped (implicitly Not Customizable).
Don't forget to document your new customization point.

Let's say that you have heard that an influential minority of customers would really like to include an invoice-generation feature as part of the application. However, you feel that a) you want to go ahead and release the first version without this functionality, b) every customer will probably want to do invoicing differently from every other customer, and c) Process Designer and BMC Helix Innovation Studio will be a great way to allow customers to extend the application into this area themselves.

Add an Invoicing Customization Point

Let's quickly build the customization point.

The customization point will be called Prepare Custom Invoice. It will operate on an Order, and be invoked as part of the Order Lifecycle, whenever an Order goes into a Closed state.
Before implementing the stub, you must change the Order Record Definition to be Public Scope (but leave it as not Customizable). This is because consumers will not be allowed to tailor the Prepare Custom Invoice process if it refers to an Application Scoped definition.
Create the new Prepare Custom Invoice stub process. Since this is a simple default, it should do nothing when it runs.

Make sure that the Scope / Customization Options are set to allow customization, and that it takes an Order Input Parameter.
Update the Order Lifecycle process to perform a Call Activity on the stub process. Make sure it accepts an Order Record as its Input Parameter. All other data associated with the Order, such as cost, department, and so on, can be obtained later using associations of Order.
Create some documentation about this customization point, so that consumers will know that they can easily define their own "child process" about invoicing and plug it in here.

That's it! We have now created a great customization point that opens up our application for customization in a specific area, will leaving the bulk of the logic, that relies on Status changes for the UI to work correctly, safely locked-down.

Challenge

Dream up your own customization point. A great one would be Approve Order. You could consider having your default Approve Order process have an Output Parameter that is always indicating approval. Your customers could override (Customize) the Approve Order process, either by using the out-of-the-box Approval Service, or by doing something else that makes sense to them. The nice thing here is that your master Order Lifecycle process can remain untouched.

What you Learned

You can provide means for customers to consume new functionality by means of customization; that is, using BMC Helix Innovation Studio to create their own Records, Views, and Process.
One especially good way to combine Non Customizable definitions (that are evolved by the developer) and Public Scoped / Customizable definitions (that essentially belong to the customer) is this concept of a customization point. This is really just a best practice around having clearly defined interfaces.

Consider that you could actually build most of the logic of your application this way: ready to be customized safely. All it takes is some care in designing how the different parts of the business process fit together, and which ones are safe to modify.