Microsoft BizTalk Server Product Lifecycle Update
For more than 25 years, Microsoft BizTalk Server has supported mission-critical integration workloads for organizations around the world. From business process automation and B2B messaging to connectivity across industries such as financial services, healthcare, manufacturing, and government, BizTalk Server has played a foundational role in enterprise integration strategies. To help customers plan confidently for the future, Microsoft is sharing an update to the BizTalk Server product lifecycle and long-term support timelines. BizTalk Server 2020 will be the final version of BizTalk Server. Guidance to support long-term planning for mission-critical workloads This announcement does not change existing support commitments. Customers can continue to rely on BizTalk Server for many years ahead, with a clear and predictable runway to plan modernization at a pace that aligns with their business and regulatory needs. Lifecycle Phase End Date What’s Included Mainstream Support April 11, 2028 Security + non-security updates and Customer Service & Support (CSS) support Extended Support April 9, 2030 CSS support, Security updates, and paid support for fixes (*) End of Support April 10, 2030 No further updates or support (*) Paid Extended Support will be available for BizTalk Server 2020 between April 2028 and April 2030 for customers requiring hotfixes for non-security updates. CSS will continue providing their typical support. BizTalk Server 2016 is already out of mainstream support, and we recommend those customers evaluate a direct modernization path to Azure Logic Apps. Continued Commitment to Enterprise Integration Microsoft remains fully committed to supporting mission-critical integration, including hybrid connectivity, future-ready orchestration, and B2B/EDI modernization. Azure Logic Apps, part of Azure Integration Services — which includes API Management, Service Bus, and Event Grid — delivers the comprehensive integration platform for the next decade of enterprise connectivity. Host Integration Server: Continued Support for Mainframe Workloads Host Integration Server (HIS) has long provided essential connectivity for organizations with mainframe and midrange systems. To ensure continued support for those workloads, Host Integration Server 2028 will ship as a standalone product with its own lifecycle, decoupled from BizTalk Server. This provides customers with more flexibility and a longer planning horizon. Recognizing Mainframe modernization customers might be looking to integrate with their mainframes from Azure, Microsoft provides Logic Apps connectors for mainframe and midrange systems, and we are keen on adding more connectors in this space. Let us know about your HIS plans, and if you require specific features for Mainframe and midranges integration from Logic Apps at: https://aka.ms/lamainframe Azure Logic Apps: The Successor to BizTalk Server Azure Logic Apps, part of Azure Integration Services, is the modern integration platform that carries forward what customers value in BizTalk while unlocking new innovation, scale, and intelligence. With 1,400+ out-of-box connectors supporting enterprise, SaaS, legacy, and mainframe systems, organizations can reuse existing BizTalk maps, schemas, rules, and custom code to accelerate modernization while preserving prior investments including B2B/EDI and healthcare transactions. Logic Apps delivers elastic scalability, enterprise-grade security and compliance, and built-in cost efficiency without the overhead of managing infrastructure. Modern DevOps tooling, Visual Studio Code support, and infrastructure-as-code (ARM/Bicep) ensure consistent, governed deployments with end-to-end observability using Azure Monitor and OpenTelemetry. Modernizing Logic Apps also unlocks agentic business processes, enabling AI-driven routing, predictive insights, and context-aware automation without redesigning existing integrations. Logic Apps adapts to business and regulatory needs, running fully managed in Azure, hybrid via Arc-enabled Kubernetes, or evaluated for air-gapped environments. Throughout this lifecycle transition, customers can continue to rely on the BizTalk investments they have made while moving toward a platform ready for the next decade of integration and AI-driven business. Charting Your Modernization Path Microsoft remains fully committed to supporting customers through this transition. We recognize that BizTalk systems support highly customized and mission-critical business operations. Modernization requires time, planning, and precision. We hope to provide: Proven guidance and recommended design patterns A growing ecosystem of tooling supporting artifact reuse Unified Support engagements for deep migration assistance A strong partner ecosystem specializing in BizTalk modernization Potential incentive programs to help facilitate migration for eligible customers (details forthcoming) Customers can take a phased approach — starting with new workloads while incrementally modernizing existing BizTalk deployments. We’re Here to Help Migration resources are available today: Overview: https://aka.ms/btmig Best practices: https://aka.ms/BizTalkServerMigrationResources Video series: https://aka.ms/btmigvideo Feature request survey: https://aka.ms/logicappsneeds Reactor session: Modernizing BizTalk: Accelerate Migration with Logic Apps - YouTube We encourage customers to engage their Microsoft accounts team early to assess readiness, identify modernization opportunities, and explore assistance programs. Your Modernization Journey Starts Now BizTalk Server has played a foundational role in enterprise integration success for more than two decades. As you plan ahead, Microsoft is here to partner with you every step of the way, ensuring operational continuity today while unlocking innovation tomorrow. To begin your transition, please contact your Microsoft account team or visit our migration hub. Thank you for your continued trust in Microsoft and BizTalk Server. We look forward to partnering closely with you as you plan the future of your integration platforms. Frequently Asked Questions Do I need to migrate now? No. BizTalk Server 2020 is fully supported through April 11, 2028, with paid Extended Support available through April 9, 2030, for non-security hotfixes. CSS will continue providing their typical support. You have a long and predictable runway to plan your transition. Will there be a new BizTalk Server version? No. BizTalk Server 2020 is the final version of the product. What happens after April 9, 2030? BizTalk Server will reach End of Support, and security updates or technical assistance will no longer be provided. Workloads will continue running but without Microsoft servicing. Is paid support available past 2028? Yes. Paid extended support will be available through April 2030 for BizTalk Server 2020 customers looking for non-security hotfixes. CSS will continue to provide the typical support. What about BizTalk Server 2016 or earlier versions? Those versions are already out of mainstream support. We strongly encourage moving directly to Logic Apps rather than upgrading to BizTalk Server 2020. Will Host Integration Server continue? Yes. Host Integration Server (HIS) 2028 will be released as a standalone product with its own lifecycle and support commitments. Can I reuse BizTalk Server artifacts in Logic Apps? Yes. Most of BizTalk maps, schemas, rules, assemblies, and custom code can be reused with minimal effort using Microsoft and partner migration tooling. We welcome feature requests here: https://aka.ms/logicappsneeds Does modernization require moving fully to the cloud? No. Logic Apps supports hybrid deployments for scenarios requiring local processing or regulatory compliance, and fully disconnected environments are under evaluation. More information of the Hybrid deployment model here: https://aka.ms/lahybrid. Does modernization unlock AI capabilities? Yes. Logic Apps enables AI-driven automations through Agent Loop, improving routing, decisioning, and operational intelligence. Where do I get planning support? Your Microsoft account team can assist with assessment and planning. Migration resources are also linked in this announcement to help you get started. Microsoft Corporation
SAP BAPI Transactions Walkthrough
One of the ways that BizTalk can access SAP servers is by using Business Application Programming Interfaces (BAPIs). In this article, we present a general scenario where the same BizTalk orchestration processes multiple BAPI transactions received separately as part of the same Logical Unit of Work (LUW) on the SAP server.Office 365 Outlook Adapters in Action
This article presents all Office 365 Outlook adapters integrated in a simplified e-tailer scenario. The goal is to show one way to get started with the adapters in a minimal yet complete BizTalk application. The adapters are: - Office 365 Outlook Email - Office 365 Outlook Calendar - Office 365 Outlook Contact All files used in the BizTalk solution are attached. Scenario A customer (Contoso) submits a purchase order (PO) by plain text email from an Office 365 account to an e-tailer (Fabrikam). The content of the email follows a custom purchase order xml schema defined by the e-tailer. One of the elements is a due date by which the order and an invoice will be sent. Upon receiving the email, Fabrikam will do the following in parallel: - Schedule sending the customer invoice. - Create or update the customer contact information. - Send a confirmation email to the customer. On the due date, Fabrikam sends an invoice to Contoso. Receive-Side: Processing the purchase order Fabrikam implements the PO processing by using a BizTalk orchestration (shown below) and the construction of three messages: calendar event, contact, and email. The PO follows the schema: The order is received on an Office 365 email account, in plain text, with the following content in the email body: <ns0:PurchaseOrder xmlns:ns0="http://CreateEventFromPurchaseOrder.PurchaseOrder"> <PONumber>PONumber_0</PONumber> <CustomerInfo> <Name>Contoso</Name> <Email>contoso@outlook.com</Email> </CustomerInfo> <Description> <Item>Item_0</Item> <Count>5</Count> </Description> <DueDate>2020-04-08</DueDate> </ns0:PurchaseOrder> Note: In desktop Outlook, the default text format in HTML. It needs to be changed to Plain Text. In the BizTalk message constructions, the PO xml schema is mapped to calendar event, contact and confirmation email schemas. For the calendar and contact schemas, we copied into our BizTalk project the schemas provided in the BizTalk installation folder under C:\Program Files (x86)\Microsoft BizTalk Server\SDK\Schemas: The resulting maps are shown below: For contact, givenName element must be provided. The confirmation email also contains the original PO and an additional document as attachments. This is done by defining a multi-part message in the orchestration. The PO-to-email map takes care of creating the email body. Then, email attachments are added in the message assignment shape with the following code: CreateConfirmationEmail.PO = PurchaseOrderMessage; CreateConfirmationEmail.PO(Microsoft.XLANGs.BaseTypes.ContentType) = "application/xml"; CreateConfirmationEmail.Receipt(Microsoft.XLANGs.BaseTypes.ContentType) = "text"; // NOTE: all message parts must be instanciated before the context properties are assigned. CreateConfirmationEmail(OfficeMail.Subject) = "Order Confirmation for " + PurchaseOrderMessage.PONumber + " due date " + System.String.Format("{0}", PurchaseOrderMessage.DueDate); CreateConfirmationEmail(OfficeMail.AttachedFiles) = "C:\\Brochure.xml"; CreateConfirmationEmail(OfficeMail.To) = PurchaseOrderMessage.CustomerInfo.Email; All parts have to be instantiated before the context properties are assigned. For a complete list of the context properties, refer to Office 365 Outlook Email. Context properties for the calendar event (not used here) are also available and documented in Office 365 Outlook Calendar. (Attachment support for calendar events may be added in future BizTalk releases if there are enough requests for the feature.) As a result, on the customer's side, the confirmation email will look like: The orchestration is bound to an email receive port, and to calendar/contact/email send ports. The default XML receive pipeline is used in the email receive location. The setup is summarized below. Send-Side: Sending invoice on the due date Fabrikam gets notified on the due date that the invoice needs to be emailed to Contoso. The following orchestration is used to define the business flow: Once again, the BizTalk message for the email is constructed in two steps. First, Office365OutlookCalendarReceive.xsd (copied from the SDK/Schemas folder) is mapped to a custom schema defining the invoice email content. Then, the following message assignment shape is used to create the email subject and extract the recipient's email from the received calendar event, which corresponds to the second element in the attendee list (hence the [2] in the xpath): CreateInvoiceMessage(OfficeMail.Subject) = "Order Invoice for " + ReceiveEventMessage.subject; CreateInvoiceMessage(OfficeMail.To) = xpath(ReceiveEventMessage, "string(/*[local-name()='Event' and namespace-uri()='http://schemas.microsoft.com/BizTalk/Office365OutlookCalendar/Receive']/*[local-name()='attendees' and namespace-uri()=''][2]/*[local-name()='emailAddress' and namespace-uri()='']/*[local-name()='address' and namespace-uri()='']/text())"); The orchestration is bound to a calendar receive port with a 1-day time horizon to get notified within 24h before the due date. In our solution, we reuse the existing email send port bound to the first orchestration. However, a new email send port may be warranted if different default adapter properties (shown below) are required, or if invoices need to be sent from a different Office 365 email account. In Summary The Contoso-Fabrikam business scenario was implemented by integrating all Office 365 Outlook adapters in receive- and send-side transforms and orchestrations. BizTalk artifacts are attached to this article for reference.Attachments in the Office 365 Outlook Email Adapter
Starting with the release of BizTalk Server 2020, email attachments are supported by the Office 365 Outlook Email adapter. As a growing number of businesses are adopting Office 365, this new feature is an interesting alternative to the POP3 Adapter on the receive side, and to the SMTP Adapter on the send side, in scenarios such as (non-exhaustive list): Migration of existing deployed POP3/SMTP BizTalk applications to a more modern platform; Integration of Office 365 and BizTalk to transfer data via email attachment payloads; Organizations that use Outlook 365 by connecting other email accounts. The article Office 365 Outlook Adapters in Action provides an example of how to use attachments in a BizTalk ochestration. Receiving Attachments 1. Multipart BizTalk Messages The first way to receive and save attachments in the Office 365 Outlook Email adapter is by creating a multipart BizTalk message where each part corresponds to an attachment. This is equivalent to the Apply MIME decoding option set to true in the POP3 adapter configuration. The receive location transport property settings for this configuration are shown below. Note that by default, the "Include attachments" checkbox is unchecked, and it needs to be checked explicitly. As an example, let's receive the following email with attachments (as shown in the Outlook desktop app): The corresponding BizTalk message, shown in the screenshot below, will have one part per attachment. The part named "body" corresponds to the email body as sent by the server, which is with HTML body type by default in Outlook 365. Subsequent parts are named after the attachment names. Each part of the BizTalk message contains character set information, and MIME type as content type. 2. MIME Content The second way to receive attachments is by choosing MIME email payload, as shown below: In this case, the BizTalk message body will contain the entire MIME representation of the email (headers, body and attachments). Sending Attachments Let's consider an email send port with the configuration below. Send ports with transport type Office 365 Outlook Email can be configured to attach the parts of a multipart BizTalk message to an email, as well as specific files. This is the equivalent of the MessagePartsAttachments and Attachments properties in the SMTP send port configuration. For illustration, we forwarded the email with attachments received earlier. The corresponding BizTalk multipart message looked like: The email sent by the send port is shown below, in the Outlook desktop client app used by the recipient. Note that the attachment types are preserved, and the body is shown as HTML in the same way as the original email. References: Office365 Outlook Email adapter POP3 Adapter SMTP Adapter Office 365 Outlook Adapters in Action
