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
