What’s new in the April Refresh of Service Bus EAI/EDI Labs

  • Article

There are a bunch of new features that are added to this refresh. Let’s go through a summary of those. For ease of organization, lets organize the updates into categories – bridges, Service Bus Connect, Transforms, and EDI Portal

Updates to Bridges

  • FTP Source. Until now, you would have to send a message to a bridge using a message sender utility. This utility would send the message to the HTTP endpoint where the bridge is deployed. With the April 2012 release, you can now configure the Bridge to ‘consume’ a message from an FTP source. This FTP source can be an FTP Server, with or without SSL. Note that you can use this FTP source to only send a message to a one-way bridge. You cannot configure this FTP source component to receive a message from a request-response bridge. That’s why it’s termed as the “FTP Source” component that you can drag-and-drop to the EAI project’s design surface. You can get more information about FTP source at https://msdn.microsoft.com/en-us/library/windowsazure/hh949809.aspx.

 

  • Flat file support. Now that the one way bridge can consume messages from an FTP source, and in most real-world scenarios, FTP sources are used to share out flat file messages, it was imperative that the bridges support flat-file processing. So, you can now configure a bridge to process either a flat file message or an XML message or both. This is really useful because now the same bridge endpoint can be used to configure flat file and XML messages. Organizations deploying the bridge on the Service Bus won’t have to bother about deploying two different endpoints for different business partners, thereby resulting in cost savings.

How the bridge supports flat-file processing is also interesting. We all know that there are four key stages to a bridge Validate, Enrich, Transform, and Enrich (post-transform). One could argue if routing is also another stage but it’s exposed more as an action after the bridge has processed the message so let’s leave it at that. To support flat file processing, the April release of EAI/EDI labs introduces a new ‘invisible’ stage called the “Decode” stage. I call it invisible because ( a ) it is not displayed on the bridge design surface and ( b ) it can’t be configured by the end user. The reason that the “Decode” stage is hidden is also straight forward, there’s not much to do in there other than decode the incoming message. If the message received by the bridge is of content-type ‘text/plain’ the bridge recognizes that as a flat-file message, kicks in the decode stage, converts the message to an XML message and then passes it on to the Validate stage for further processing. The processing of the now transformed XML message is same as any other XML message that would have hit the bridge endpoint. So, to put it simply, the decode stage transforms flat-file to XML messages and then lets the bridge do the rest of XML processing. If the incoming message is not of content-type ‘text/plain’ the decode stage doesn’t kick in.

You can read more about the flat-file support in bridges at https://msdn.microsoft.com/en-us/library/windowsazure/hh949818.aspx

  • Generating flat file schema. OK. So, now I want to go ahead and configure the bridge to process flat file messages. The way to do this would be to use the Validate stage and as part of the request message type, specify the flat file message schema. But, where do I get the flat file schema from. I can use third party tools to generate the schema but then that’s not an integrated experience. So, to give users an end-to-end experience with flat file scenarios, the April release also introduces the Flat File Schema wizard. Given a flat file instance, this schema generates a flat-file message and adds it to the EAI project you must be creating in Visual Studio. The Flat File Schema wizard is pretty much the same as the one available with BizTalk Server. For more information about the wizard, see https://msdn.microsoft.com/en-us/library/windowsazure/hh949810.aspx
  • Schema Editor. This is something that will be useful whether we use the bridge to process XML or flat file messages. The April release of EAI/EDI Service now includes a BizTalk-like Schema Editor that you can use to hand-create a schema. Well, it’s almost BizTalk like because it does not include the support to generate an instance message for the schema. For more information, see https://msdn.microsoft.com/en-us/library/windowsazure/hh949807.aspx.
  • Service Consuming Wizard. The bridges have always supported sending messages to external WCF services (one-way or two-way). When you use the bridge to send message to an external service, you would need to have the schema of the message expected by the service as part of your EAI project. You would need that so that you could transform the message received by the bridge to the message expected by the service. Until now, there was no integrated way of generating the message schema expected by the bridge. Bridge developers would have to rely on out-of-band experiences to generate the schema and then add that schema to the EAI project. The April refresh of EAI/EDI Labs service now includes a Service Consuming Wizard that you could use to generate the schema from the EAI project itself. This Visual Studio add-in generates the schema and also adds it to the EAI project. Sweet!! For more information, see https://msdn.microsoft.com/en-us/library/windowsazure/hh949814.aspx
  • Operational Tracking. THE BIG ONE!! We all wanted this. How do I track the message once the bridge start’s processing it? If the processing fails, how do I know what happened and where? Such and many more questions always came up whenever we talked of bridges and message processing. These have now been addressed to a large extent. As part of the bridge configuration, you can now configure operational tracking, which would do the following:
    • Track the completion/faulting of different stages within a pipeline
    • Track the processing of route and send actions
    • Track the message properties that you would have promoted in the Enrich stages

While you can enable tracking through the the Bridge Configuration design surface, you can retrieve the tracking data only through the REST interface. For more information, see https://msdn.microsoft.com/en-us/library/windowsazure/hh949804.aspx.

Updates to Service Bus Connect

  • Support for Windows Authentication. You can now use Windows Authentication to connect to an on-premise LOB Server. However, for the April release, this support is limited to only connect an on-premise SQL Server instance.
  • Support for SSL. With the SSL support, you can now setup the Service Bus Connect Management Service with SSL enabled. To do so, you can specify an SSL certificate while you are installing the Service Bus Connect component as part of the Service Bus EAI & EDI Labs installation. Having said that, you might want to overlook some SSL-related errors at design time when you are setting up your solution. To do so, Service Bus Connect provides the option of ignoring such SSL/certificates related errors from the Server Explorer and also provides command line options to skip certificate check using the PowerShell cmdlets.
  • New user interface for configuring LOB Targets. The user interface we had for creating LOB Targets was pretty much a reuse of the Consume Adapter Service wizard available with BizTalk Adapter Pack. This has been completely remodeled in the April release to have a wizard-based approach. You can read more about this at https://msdn.microsoft.com/en-us/library/windowsazure/hh689892.aspx.

Updates to the EDI Portal

  • Deleting/Redeploying Agreements. This is a major ask addressed and this was addressed in a refresh a little before the April refresh. I am still putting this in the list of feature additions just to have all the new features listed in a single place. The EDI Portal now gives you the option to either delete an agreement or make changes to an existing agreement and redeploy.
  • Support for Batching. As part of the EDI send-side processing, you can configure the agreement to batch messages before sending them out to the intended partner. You can specify the batch size which would denote the number of messages that need to batched into one single message before being sent out. For more information, see https://msdn.microsoft.com/en-us/library/windowsazure/hh949816.aspx
  • Support for tracking and archiving EDI messages. The EDI portal now has a “Tracking” tab that lists all the tracking information for messages processed by the agreements that you configured to process EDI messages. The Tracking page lists data like what HAT /Group Hub page used to do for BizTalk Server. For more information on EDI tracking, see https://msdn.microsoft.com/en-us/library/windowsazure/hh949805.aspx

Updates to Transforms

  • New map operations. The April refresh of Service Bus EAI/EDI labs introduces some new map operations.
    • Number format – Formats a give number to a specified format.
    • Date/Time Operations – Provides date time manipulations such as AdjustTimeZone, GenerateDateTime, etc.
    • GenerateID – Generates a new unique ID and assigns it to a specified element in the destination schema.
  • Runtime Behavior Configuration – With the April refresh of EAI/EDI labs you can configure the map to behave the way you want in case there is a runtime error during message transformation using the map. You can configure the runtime behavior for how the transform handles exceptions, errors, null values, and empty data input. This configuration can be done for each transform.

So, get started and get your hands dirty with the April refresh. Share your feedback at the EAI/EDI Labs MSDN forum at https://social.msdn.microsoft.com/Forums/en-US/servicebuslabs/threads.