Introduction
To capture and query business activity, BizTalk Server comes with the Business Activity Monitoring (BAM) framework. With BAM, business users can define which business entities are relevant for them and they can keep track of the business transactions that flow through the BizTalk platform. BAM is one of the optional, and underestimated, features of BizTalk Server.
However, although BAM clearly has business value, it also has some down sides and limitations that probably has lead that BAM has not been adopted widely by BizTalk users. In this blog, we want to shortly point out some of these down sides and limitations and show you how to address them by migrating to Atomic Scope.
Down sides and limitations of BizTalk BAM
When you are already using BAM, besides seeing the benefit of BAM, you might have also experienced the disadvantages of BizTalk BAM. Some of these disadvantages are:
- Complex to implement – it takes multiple steps with different tools to implement BAM and be able to track transactions in the BizTalk BAM portal
- Time-consuming deployments – even the deployment of simple changes like adding/removing entities to BAM views is time-consuming
- No support for hybrid integrations – BizTalk BAM supports only transactions that run in BizTalk Server. Hybrid scenarios that involve Logic Apps or Azure functions are not supported
- BAM portal deprecated in BizTalk 2020 – Although the portal can still be installed, this could be an indication that Microsoft is moving away from BAM and BAM users should search for alternatives (like Atomic Scope)
Addressing the BizTalk BAM down sides with Atomic Scope
When we, at Kovai.co, realized these limitations exist, we immediately felt like wanting to address these limitations. We took the time to properly design Atomic Scope, the product that addresses these issues. During the design of the product, we focussed on among other things the following topics:
- Addressing the pain points that come with BizTalk BAM
- Making Atomic Scope powerful and feature-rich
Let us have a short look at what we did to realize these goals.
Addressing the pain points that come with BizTalk BAM
There were a couple of pain points in BizTalk BAM, that we really wanted to address. We will have a short look at them now.
Making Atomic Scope easier to implement
While implementing BizTalk BAM requires different tools and products like Microsoft Excel, the Tracking Profile Editor (TPE) and the command-line tool bm.exe, we wanted to make the implementation of Atomic Scope as easy as possible, by having people using the Atomic Scope portal for different tasks. This way, tasks like setting up the business process configuration, configuring the entities that should be tracked, assigning user permissions, and setting up of monitoring, can all be done in one place, where you would need to use multiple tools when implementing BizTalk BAM.
By reducing the number of required tools and bringing all the required capabilities to a web portal, we achieved the design goal to make Atomic Scope easier to implement than BizTalk BAM.
Prevent time-consuming deployments
BAM views contain all the information about what should be tracked by BizTalk BAM. Once a BAM view has been created and deployed, and data becomes tracked, you can view the data in the BAM portal. The below screenshot shows how the BAM portal looks like with a simple BAM view.
In case you want to change the configuration of tracked fields, like adding or removing fields, you need to update the BAM view and redeploy it. As this process is quite time-consuming, we wanted to prevent this from happening when people are using Atomic Scope.
With Atomic Scope, it is just a matter of updating the Business Process configuration via the Atomic Scope portal. Without redeployment or any other action, any changed configuration will immediately be picked by the Atomic Scope runtime!
Making Atomic Scope powerful and feature-rich
Besides addressing the pain points we found in BizTalk BAM, we wanted to make the product feature-rich and powerful. Therefore, we brought features and capabilities to better support customers who are migrating from BizTalk BAM to Atomic Scope, but we also brought other features. In fact, if our customers come with a request for Atomic Scope, we evaluate the request and explore if it would benefit other customers as well. If so, chances are that we will implement the request in the product!
Just a couple of the features we brought to the product are:
- End to end tracking – track, view and monitor your BizTalk integrations
- Support for hybrid integrations – track, view and monitor your hybrid integrations
- Monitoring – monitor your business transactions and be notified of anomalies
- User Access Policies – provide role-based access to the stakeholders of the integrations
- Analytics dashboards – dashboards with standard and customizable widgets to show statistical information about your business processes
- Message reprocessing – fix and reprocess faulty messages
Of course, there is much more possible with the product. If you want to have more insights in the product, feel free to reach out to us via support@atomicscope.com. You could also check the web site or the Documentation portal.
How to migrate from BizTalk BAM to Atomic Scope
Now, let us assume that you have already implemented BizTalk BAM and you want to migrate to Atomic Scope. To understand how you should implement Atomic Scope, you should firstly understand how your BAM Views and Activities look like and how they can be mapped to entities in Atomic Scope.
Exploring a BAM View
The below screenshot shows a BAM View called BAMTraining (1.) that contains 2 Activities called InboundOrder and OutboundOrder (2.), and the fields (3) that contain tracked data.
To configure to which actual message elements these fields must be mapped, with BizTalk BAM you can use the Tracking Profile Editor (TPE). In below screenshot, TPE shows the tracking profile for the InboundOrder activity.
On the left side of the tool, you can see (most of) the fields that we have seen in the previous screenshot as well; currently, the field OrderId is selected. All fields on the left side must be mapped to, for example, an element in a schema or a context property. In the right side of the screen, you can see that the OrderId field of the BAMTraining.InboundOrder has been selected. This means that the field OrderId is mapped to the field OrderId of the BAMTraining.InboundOrder schema. Similarly, you can explore to which elements the other fields are mapped. This information helps in setting up the configuration in Atomic Scope.
Mapping BAM multiple concepts and tools to Atomic Scope
Before we move on to migrating BAM to Atomic Scope, let’s shortly have a look how several BizTalk BAM entities can be mapped to Atomic Scope.
With BizTalk BAM, we have seen multiple concepts and tools. The below overview gives an overview of the most relevant ones and their Atomic Scope counterparts.
- BAM Views – A BAM View can contain one or more Activities that represent a specific business transaction. Although not exactly the same, the counterpart of a BAM View in Atomic Scope would be the Business Process, as Atomic Scope Business Processes contain Atomic Scope Transactions that represent a specific business transaction
- Activities – An Activity in BAM represents a specific business transaction. For example, the BAM View we have explored earlier has the Activities InboundOrder and OutboundOrder. The Atomic Scope counterpart of a BAM Activity is the Transaction. An Activity in BAM has the information about what fields should be tracked. In Atomic Scope however, this information is stored as Stage properties
- BAM Portal – Among other things, the BAM Portal allows users to explore BAM Views and Activities, query Transactions and set up Alerts. In Atomic Scope, you can query the transactions in the Tracking Alerting can be set up in the Monitoring section
- Tracking Profile Editor (TPE) – Once you have determined the fields that must be tracked (in Excel), you must map these fields to actual message elements or context properties. This can be done with the Tracking Profile Editor. In Atomic Scope, determining the fields that must be tracked and configuring their mapping to actual message elements, context properties or constants is done with Stage properties
Creating Business Process configuration in Atomic Scope
Now we know which fields we want to show in Atomic Scope, how these fields are mapped to message elements and context properties and understand BizTalk BAM concepts versus their Atomic Scope counterparts, we can start the actual migration.
We assume that you have installed Atomic Scope and an active license is in place.
In line with the set up in BAM, we will create the following in Atomic Scope:
- A Business Process called BAMtraining
- In the BAMTraining Business Process, we create a Transaction called InboundOrder
- In the dropdown Direction, select Inbound
- In the Transaction InboundOrder, we create a Stage called ReceiveOrder
- In the dropdown Executed At, select BizTalk Receive
- In the Stage ReceiveOrder, we create a Global Property called OrderId
- Click Configure Global Properties to create a property called OrderId
- Click Add Property, select Global
- In the blade that appears, perform the following:
- In the dropdown Property Name, select OrderId
- In the dropdown Property Source, select XPath
- In the field Property XPath, enter //OrderId/text()
- Store the configuration you have just created, by clicking Save
Compared to the set up in BAM, you must have noticed a couple of differences:
- The configuration of Stages – compared to BAM, this is an additional layer that enables you to add properties for mapping of fields to message elements, context properties and constants. Each Stage is one part of a transaction, like receiving a message in a Receive Location, processing a message in an orchestration, or transmitting a message vie a Send Port. It also enables you to add Dynamic properties for routing and configure Reprocessing of messages
- Mapping is done with XPath queries – no need to know the schema that contains the elements that should be tracked or use other tools to map fields to message elements or context properties! Once you have a message instance, you can simply derive the XPath to the required element
Once you are used to these differences, we are confident that you will understand how powerful the detailed configuration at the Stage level is.
The above explanation should help to get you started with setting up the Business Process configuration in Atomic Scope. Optionally, you can create Stages and Stage properties for the remaining elements from your BAM View.
By creating the Business Process configuration, we are half-way with the creation of an end-to-end overview of a business transaction in Atomic Scope. Now, we need to instrument the BizTalk solution that processes the business transaction.
Instrumenting your BizTalk solution
At a high level, to instrument your BizTalk solution with the Atomic Scope components, the easiest way is to open the BizTalk Server Administration Console, navigate to the BizTalk application that contains the BizTalk solution and make the changes there.
To enable Atomic Scope to pick up the values of the tracked fields, the product comes with pipelines and pipeline components that you must use in the ports where the tracking should be done. For tracking activity in orchestrations, you can use helper classes that also come out-of-the-box with the product.
Note: The product also comes with components for tracking activity in Azure Logic Apps and Azure functions.
You need to perform the below steps to instrument a port via the BizTalk Administration console:
- Open the BizTalk Admin console
- Navigate to the BizTalk application that contains the solution that needs to be tracked
- Open the Receive Location where messages that should be tracked will be received by BizTalk
- At the Receive pipeline, select the XMLReceivePipeline pipeline from Atomic Scope. If it does not show up in the dropdown, you might have to create a reference to the AtomicScope In case you are using a custom pipeline, you could add the Atomic Scope custom pipeline component to your custom pipeline in your Visual Studio solution
- Once the pipeline has been selected, click the ellipsis button to configure the pipeline. The XMLReceivePipeline pipeline has three stages
- At Stage 1 (Decode), we provide the following configuration:
- ArchiveMessage: True
- BusinessProcess: BAMtraining
- BusinessTransaction: InboundOrder
- StageName: ReceiveOrder
- StartActivity: True
- UpdateActivity: True
The screen will look like shown below:
- Click OK to close the window, click OK again to save the configuration
With the above settings, we made sure that processed messages would be archived in Atomic Scope and that the transaction, including the tracked fields will become visible in the Atomic Scope Tracking portal.
So far, we have only configured a simple process with only one stage, and one tracked field. Normally, you will want to track much more than just that. We provide a couple of examples out-of-the-box, that you can try yourself in your environment. These examples are documented in the Documentation portal. You can check this page in that portal, to understand a bit more complete scenario that you can try yourself in your environment.
Conclusion
With this blog, we intended to explain a couple of the advantages of Atomic Scope over BizTalk BAM and explain a couple of BizTalk BAM concepts and tools and their counterparts in Atomic Scope. We finished with explaining how to migrate from BizTalk BAM to Atomic Scope.
Hopefully, we successfully made clear that Atomic Scope is a valuable product to keep track of your business transactions.
Do you want to know more about Atomic Scope? Feel free to reach out to us (support@atomicscope.com) to have an open conversation, without any obligations. We would also be happy to show you the product during a demo. Alternatively, you could try the product yourself by taking a free trial for a limited time.
