Windows Equivalent To Logic Pro X
Reyes Grindberg
This guide provides an overview about the reasons and benefits, product comparisons, capabilities, and other information to help you start migrating from on-premises BizTalk Server to cloud-based Azure Integration Services. Following this guide, you'll find more guides that cover how to choose the services that best fit your scenario along with migration strategies, planning considerations, and best practices to help you deliver successful results.
Azure Integration Services includes the following cloud-based, serverless, scalable, and Microsoft-managed building blocks for you to create comprehensive integration solutions and migrate existing BizTalk Server solutions:
Beyond the previously described services, Microsoft also offers the following complementary services that provide underlying capabilities for Azure Integration Services and which you'll likely use in a migration project:
To compare BizTalk Server with Azure Integration Services and discuss how to migrate, let's first briefly summarize what BizTalk Server does. Originally available in 2000, BizTalk Server is an on-premises, stable, middleware platform that connects various systems by using adapters. This platform works as a broker between businesses, systems, or applications and is now a well-established integration platform. To simplify the challenge in combining different systems that are developed in different languages and can be connected using different protocols and formats, BizTalk Server offers the following main capabilities:
BizTalk Server uses a publish-subscribe messaging engine architecture with the MessageBox database at the heart. MessageBox is responsible for storing messages, message properties, subscriptions, orchestration states, tracking data, and other information.
When BizTalk Server receives a message, the server passes and processes the message through a pipeline. This step normalizes and publishes the message to MessageBox. BizTalk Server then evaluates any existing subscriptions and determines the message's intended recipient, based on the message context properties. Finally, BizTalk Server routes the message to the intended recipient, based on subscriptions or filters. This recipient is either an orchestration or a Send port, which is a destination to where BizTalk Server sends messages or source from where BizTalk Server can receive messages. BizTalk Server transmits messages through a Send port by passing them through a Send pipeline. The Send pipeline serializes the messages into the native format expected by the receiver before sending the messages through an adapter.
In BizTalk Server, orchestrations are executable business processes that can subscribe to (receive) messages and publish (send) messages through the MessageBox database. Orchestrations can construct new messages and can receive messages using the subscription and routing infrastructure. When MessageBox fills subscriptions for orchestrations, a new instance (orchestration run) activates, and MessageBox delivers the message. If necessary, the instance is rehydrated, and the message is then delivered. When messages are sent from an orchestration, they're published to MessageBox in the same way as a message arriving at a receive location with the appropriate properties added to the database for routing.
To enable publish-subscribe messaging, orchestrations use bindings that help create subscriptions. Orchestration ports are logical ports that describe an interaction. To deliver messages, you must bind these logical ports to a physical port, but this binding process is nothing more than configuring subscriptions for message routing.
Design processes with focus on the messages, not the end system. For example, while developing your solutions, you don't have to worry about whether you're going to use a FILE adapter or an FTP adapter. Instead, you focus on the communication type, whether one way or request-response, and on the message type that you want to process. Later, when you deploy your solutions, you can then specify the adapter and the end systems.
In Azure Logic Apps, you can create executable business processes and applications as logic app workflows by using a "building block" way of programming with a visual designer and prebuilt operations from hundreds of connectors, requiring minimal code. A logic app workflow starts with a trigger operation followed by one or more action operations with each operation functioning as a logical step in the workflow implementation process. Your workflow can use actions to call external software, services, and systems. Some actions perform programming tasks, such as conditionals (if statements), loops, data operations, variable management, and more.
Select from a constantly expanding gallery with hundreds of prebuilt connectors to build your workflows. A connector provides operations that you can use as steps in your workflows. You can build integration solutions for most services and systems from both Microsoft and partners, including BizTalk Server, Salesforce, Office 365, SQL databases, most Azure services such as Azure Functions, Azure Storage, Azure Service Bus, and many others plus on-premises applications or systems, mainframes, SaaS, and APIs. If no prebuilt connector exists for the resource that you want to access, you can use the generic HTTP operation to communicate with the service, or you can create a custom connector.
Integration platforms offer ways to solve problems in a consistent and unified manner, which you can often achieve through reusable components. This section describes how you can reuse components in BizTalk Server and Azure Integration Services.
You can create and share common business logic as orchestrations across different workflows, internally inside the same application or with multiple applications. You can trigger orchestrations by using the native publish-subscribe mechanism in BizTalk Server (in a decoupled way) or by using the orchestration shapes named Call Orchestration for synchronous calls or Start Orchestration for asynchronous calls.
Adapters are software components that provide connectivity between BizTalk Server and trading partners using commonly recognized data protocols and document formats. These components make sending and receiving messages easier by using a delivery mechanism that conforms to a commonly recognized standard, such as SMTP, FTP, HTTP, and more. Adapters are part of the core platform, so all existing applications share them. You can also extend this layer by creating a custom adapter, either native or based on Windows Communication Foundation (WCF), by using the BizTalk Adapter Framework.
XML Schema Definition (XSD) schemas enable contract-based messaging in BizTalk Server. To avoid creating redundant schemas, you can reference schemas from compiled assemblies. To use shared schemas, you must add a reference to the shared assembly from your BizTalk project.
While this step might sound simple, managing changes to shared assemblies might become difficult due to dependency chaining. If the shared assembly requires an update, you must remove all projects that reference the shared assembly from BizTalk Server to install the update. However, to avoid these constraints, you can implement assembly versioning where you deploy a new version for a schema or shared schemas without breaking your existing solutions.
Maps enable XML message translation or transformation in BizTalk Server. You can share maps, but like shared schemas, similar cautions apply to shared maps. Due to dependency chaining, proceed carefully and make sure that you have a mature software development lifecycle to manage change.
In maps, functoids perform calculations by using predefined formulas and specific values called arguments. BizTalk Server provides many functoids to support a range of diverse operations. Custom functoids provide a way for you to extend the range of available operations in the BizTalk Server mapping environment.
If you start to create many maps, you'll realize that you're repeatedly implementing similar logic. Consequently, you'll find yourself spending time maintaining multiple equivalent code snippets that you usually copy and paste into several locations within a map or across maps. Consider transforming such code snippets into a custom functoid. That way, you create the functoid only once, but you can reuse the functoid in as many maps as you want and update the functoid in only one place. Each custom functoid is deployed as a .NET assembly using classes derived from the Microsoft.BizTalk.BaseFunctoids namespace. A single assembly can contain more than one custom functoid.
You can share these assemblies across BizTalk Server projects. These assemblies are easier to manage from a dependency perspective. Provided that no breaking changes exist, an update to a .NET Fx assembly requires updating the DLL in the Global Assembly Cache (GAC), which automatically makes the changes available to other assemblies. If breaking changes exist, you must also update the dependent project to accommodate the changes in the .NET Fx assembly.
When BizTalk Server receives and sends messages, the server might need to prepare and transform messages for entry and exit, due to business reasons. In BizTalk Server, pipelines provide an implementation of the Pipes and Filters integration pattern and include many features such as a JSON encoder and decoder, MIME or SMIME decoder, and so on.
When you need to add information to the context of a message that requires pipeline customization, BizTalk Server provides the capability to customize these pipelines by creating custom pipeline components. A custom pipeline component is a.NET class that you use to implement multiple BizTalk interfaces and then use inside different stages of any custom pipeline. To write code for such a component, you can use C# or Visual Basic for .NET.
A Business Rules Engine policy is another kind of artifact that you can share across BizTalk Server applications deployed within the same BizTalk group. If you have common Business Rules Engine rules, for example, related to message routing, you can manage these rules in one location and share them widely across installed BizTalk applications. The Business Rules Engine caches these rules, so if you make any updates to these rules, you must restart the Business Rules Engine Update Service. Otherwise, the changes are picked up in the next Cache Timeout.
d3342ee215