We are excited to introduce Azure Integration Environment, a new unified experience that helps customers manage and monitor their integration resources effectively. This platform enables customers to organize their resources logically, providing business context and reducing overall complexity. By using this platform, customers can leverage integration as a strategic advantage, unlocking new opportunities and streamlining operations.
Initially, there are two core components that make up this new unified experience:
Note: Integration Environment and Business Process Tracking are currently in preview and not yet ready for production use. See Supplemental Terms of Use for Microsoft Azure Previews.
Update: We have updated the pre-requisites below to reflect registering a Resource Provider within your Azure subscription.
Integration environment allows organizations to assemble their resources into logical groupings. The model is flexible to allow organizations to use integration environments in a way that aligns with internal standards and principles. For some organizations this may mean grouping integration environments based upon traditional landscapes such as development, test, staging, user acceptance testing and production. For others, they may decide to group resources based upon business units or organizations such as Finance, Marketing, Operations, Corporate Services. Regardless of your organization’s structure, you should find the flexibility needed to address your requirements.
Within an integration environment, we are also introducing an application concept that allows you to further break down an environment into additional logical groupings. For example, within a production integration environment, you may see many applications, with each one fulfilling a specific purpose such as: payroll, order processing, employee onboarding, bank reconciliation, shipping notifications etc.
Creating an application involves providing a name for the application and then associating existing resources within the same Azure subscription. The resource types that are currently supported include:
We have plans to include additional resource types in the future. Please refer to Future Investments section later in this document for upcoming plans.
The focus for Business Process Tracking is to bring “business context to integration”. We have heard from customers that they are looking for the ability to track key business data as it moves through their integration solutions.
An important requirement that customers had for us as we were designing this experience is that they do not want to embed any tracking information directly in their workflows. They want to decouple the tracking implementation from the actual solution. We stayed true to this requirement by providing a business process designer within the Azure Portal. The business process designer allows an author to construct a series of business process stages. Within each of these stages, properties can be created that refer to key business data that the business SME would like to capture. The target audience for this business process designer is a business analyst or a business subject matter expert.
Once a business analyst has defined the business process, we envision a developer to subsequently build upon this business process by selecting within logic app workflows where data can be retrieved from so that business process properties can be gathered. To select the point in time that the data properties will be sent, a developer will use a read only version of the logic apps workflow designer and select an action and any dynamic content they would like to emit.
To illustrate how we can use Business Process Tracking, let’s consider a use case from the utilities industry that involves a customer service power outage business process. In this case, our utility named City Power & Light needs to track the status of their power outage process as it moves across 3 different systems.
As you can see below, we have a very structured business process and at each stage, we have properties that we would like to capture. You will also notice that across each stage we have Ticket Number. This is the value that we use as our Business Identifier that will allow for all events that are emitted to be aggregated.
Next, we want to create an application within our Integration Environment that allows us to relate all the Azure resources that make up our power outage business process.
To create the application, perform the following steps:
We can click into our newly created application and create a business process that allows us to model our actual business process. To do this, perform the following steps:
Inside our business process, we can add stages and create data properties for each stage. In the Customer Service Power Outage business process that was outlined above, we want to create six stages that represent our business process. For each stage we want to define our key business properties that allow us to gain insights into our business process.
To add a stage, we need to perform the following steps:
Note: When creating stage and property names, spaces are not allowed. You can use ‘-‘ or ‘_’ as word separators.
Note: We will automatically capture a timestamp as each stage is processed, so you don’t need to add a timestamp that represents when this stage completed.
Note: The business process represented above is a sequential workflow, but it doesn’t have to be. We have recently added support for parallelism. To add a parallel branch, click the + in between two stages.
We now need to map our conceptual business process to our actual Logic Apps (Standard) implementation. For each stage, perform the following actions:
To deploy the Business Process, you need to have access to the logic apps that have been used in the mappings. The reason for this is that we will create a tracking profile in each of the logic apps that are participating in the business process. These tracking profiles will be added to the logic app’s Artifacts folder within the TrackingProfiles sub-directory.
Note: Your ADX instance must be online for a deployment to take place and for records to be ingested. In addition, deployments will cause the impacted logic apps to automatically restart.
Deployment is currently only available in the Azure Portal, and we have not provided an ability to export and import business profiles at this point in time. To deploy a business process, perform the following steps:
We now have an active business process that should be in a deployed state and are ready to run transactions through our logic app(s). We can determine that our business process is deployed by the green checkmark displayed in the Deployed column.
To view our transactions, click on the table with the magnified glass.
Within our Transactions experience we will see any records that have been tracked by our solution. We can filter based upon our Business Identifier and Time range.
For a particular transaction, we can click on our Business identifier and that will open up a panel which will display the status of our business process.
We can further drill into a specific stage by clicking on it. When we do, we will see the tracked properties for that stage.
Beyond the out of box report that we provide here, you can also use Azure Workbooks or Power BI to build custom experiences.
As this feature is in public preview there are some future areas of investment that we are actively tracking. We are really interested in customer feedback to help prioritize these needs:
When creating an Integration Enviornment, you must provision it in one of the following regions. You can still associate resources from outside that region, if you choose, but it must be in the same Azure subscription.
If you would like to view this content in video format, check out the following YouTube video:
If you have feedback, we would love to hear from you. Please drop a comment below and we can arrange for a follow-up to further discuss your scenarios.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.