> Issue LXV, August 2012 > EAI and EDI in the Cloud: Prospects of Azure Service Bus EAI & EDI – Part I
Manfred Steyer

Manfred Steyer


Manfred Steyer ( is a freelance trainer and consultant at IT-Visions ( He also coordinates the specialist field of "Software Engineering" of the Degree Programme in "Information Technologies and Business Informatics" at CAMPUS 02, University of Applied Sciences ( in Graz, Austria. In cooperation with Holger Schwichtenberg, he describes the joint use of WCF, WF, WIF, Entity Framework and Azure Service Bus for company applications in his current book "Verteilte Systeme und Services mit .NET 4.0: Konzepte und Lösungen mit WCF 4.0".


rss  subscribe to this author


EAI and EDI in the Cloud: Prospects of Azure Service Bus EAI & EDI – Part I

Published: August 20th, 2012 • Service Technology Magazine Issue LXVI PDF

Abstract: This is the first article in a two-part series that discusses how in the future, the EAI features of Azure Service Bus will offer the transformation and routing of messages to integrated systems on a pay-per-use basis while maintaining its usual high availability. Moreover, standards like EDIFACT and X12 will also be supported in the same way as the integration into local systems via relaying.


System integration solutions are a single point of failure and, as such, must be designed to be fail-save. This results in higher hardware and software licensing costs and, consequently, often makes professional ESB offers unattractive. Azure Service Bus's pay-per-use solution provides a remedy for this problem.The current version concentrates on message mediation and, among other features, offers queues to enable reliable communication as well as topics for publish/subscribe scenarios. However, looking at the CTP [REF-1] which is currently available hints that this is just the beginning. Hence we can expect to see possibilities for transforming and routing messages in the future. Moreover, flat files, especially for X12 and EDIFACT, will be widely supported, and the integration of local business applications and databases will be facilitated.

It is always advisable to install CTPs on a test system, such as a virtual machine. With regard to the CTP in question, special attention must be paid to documented installation requirements and dependencies, otherwise the setup routine may not be performed successfully.

Message Transformations Using Maps

If two systems that are to be connected expect messages in different formats, these must be transformed, which can be done using maps rather than programming. A map assigns elements of a message definition to its counter pieces in another message definition. Thereby, an XML schema is to be given for the source message and for the target message. Fig. 1 depicts a map which maps the elements of the PlaceOrder message to elements of the the SendOrder message. The last three elements are not mapped 1:1 to the respective elements of the target schema, but serve as an access parameter for a String Concatenate (symbol labeled A+B) type map operation. As the name suggests, this operation brings different values together in a string. In the present case, this string is assigned to the ShipTo field. A number of other map operators are to be found in the Toolbox.

This particular map may be used when a client who generates a PlaceOrder type message is meant to communicate with a service expecting a SendOrder type message. For the sake of completeness, Fig. 2 depicts another map mapping the response of SendOrder to the response belonging to PlaceOrder.

Figure 1 – Converting a request.

Figure 2 – Converting a response.

Connecting Systems Using Bridges

Bridges help to connect two heterogeneous systems. A distinction is made between one-way bridges and two-way bridges. In the case of a one-way bridge, the application only sends a message to the recipient, whilst when a two-way bridge is used, the application sends a message to the recipient and the recipient sends a response back. Bridges can be used to validate, enrich and transform messages using maps.

Fig. 3 displays a bridge configuration which was set up using the drag-and-drop function in Visual Studio. A two-way bridge is used here which routes the received messages to a service. Being a two-way bridge, it does not ignore the response message of this service. To define via which address the bridge should be accessible later on, the desired value is entered in the properties window under Relative Address. The complete address is composed of the combination of the chosen Azure namespace (see below) and this relative address.

The service in this example is a SOAP service connected through a relay binding. This means that the service is performed locally and registers with the service bus when booting up. The service bus assigns a public address to the service and from then on any and all messages sent to this address are routed to the service. Therefore, the service bus uses the connection which was initially set up by the local service thereby rendering the entire process firewall-safe.

Figure 3 – Bridge configuration.

The SOAP message to be sent to the service must have a SOAP action header so it knows with which service operation to associate the message. This can be created in Visual Studio using the Route Action function which is offered to connect the bridge to the service. Fig. 4 shows the dialog connected with this property. The Property (Read From) section defines where the value to be used can be obtained. Either a dropdown list with so-called context variables (Property Name) or a textbox in which an expression can be entered are to be selected.

In this particular case the latter is used; we will, however, look at context variables later on. That is why the desired value, SendOrder, is in this textbox. But as the textbox expects to receive an expression, SendOrder must be entered in inverted commas showing that it is a string.

The Destination (Write To) section is used to clarify how the value which has previously been defined should be used. The Type option defines if the value is to be assigned to an HTTP header or a SOAP header. The name of this header must be entered into the Identifier field. In the given example, the SOAP header Action is addressed.

Figure 4 – Defining a route action.

In addition to this, a Filter property (Fig. 5) is offered by the connection between the bridge and the service. It defines under which circumstances the message should be routed from the bridge to the service. As the bridge is only connected to one single service in the present case, the MatchAll option was chosen.

Figure 5 – Definition of a filter.

As well as the relaying service used in this example, other types of message recipients can also be configured. An overview thereof is given in the Toolbox (Fig. 6). The elements given under On-Premise LOBs offer the possibility to send messages directly to a local system (an "on-premise line-of-business-system"). Here, relaying is complemented by LOB adapters which are to be installed locally and originate from the BizTalk Server universe. An example for this is given further below. In the Route-Destinations section the Toolbox offers elements which are also able to address public services (One-Way External Service Endpoint and Two-Way External Service Endpoint). In addition, messages can be sent to a queue or a topic.

Figure 6 – Elements needed when setting up a bridge configuration.

Restrictions of Combining Two-way and One-way Bridges

When setting up bridge configurations it is important to bear in mind that messages from two-way bridges cannot be sent to elements working according to the one-way principle. When the one-way principle is used, requests cannot be answered, but the two-way bridge depends on this function. This means that, for example, it is not possible to send messages from a two-way-bridge to a queue, a topic or a one-way bridge. On the contrary, messages from a one-way bridge can in fact be sent to a two-way bridge. The message returned by the two-way bridge however will then be ignored.

Configuring Bridges

Once the bridge configuration has been set up, its elements must be configured. A double click on the bridge or the selection of the appropriate element in Solution Explorer will lead you to a configuration dialog which supports this task. Fig. 7 depicts this dialog for a two-way bridge. In the upper area, the message definitions of the messages which may be sent to the bridge are to be selected under MessageTypes in the Request Message Type section. These are appropriate XML schemas. Moreover, the definitions of the response messages are listed under Response Message Type.

Incoming as well as outgoing messages go through four so-called stages in which they may be validated, enriched or transformed. The stages for incoming messages are listed on the left pane; the stages for outgoing messages are listed on the right pane. In the present case, for example, it has been defined that the incoming message be transformed with the A-to-B-Request map and the outgoing message with the B-to-A-Response map. The SOAP Action to be used for transferring the outgoing response message was defined in the Send Action stage as PlaceOrderResponse using the property with the same name.

One-way bridges are configured similarly; here, however, the right area, which refers to response messages, becomes obsolete.

Figure 7 – Configuring a bridge.

Configuring Relay Bindings

The configuration of the relay service does not have its own dialog. Instead, a double click on the bridge configuration leads to a configuration file, in which a WCF client endpoint, which refers to the service, is to be configured (Listing1). It refers to a relay binding and a public address for which only the latter part is given. The other part of this address corresponds to the namespace, under which the application is provided (see following paragraph). In the present case basicHttpRelayBinding and the /OrderServiceB address are used.

      <clear />

Providing a Solution

To allow the configured bridges actually to be used, they must be provided to the service bus via a namespace. These namespaces are to be created in the Management Portal. Since the possibilities observed are currently still in the CTP phase, the Laps Portal [REF-2] is to be used. The name of the namespaces must be unique. The Servicebus option is to be activated for the namespace in order to provide for the necessary functionalities.

To create an EAI project within such a namespace, the namespace must first be entered in the Service Namespace property when configuring the bridge. Subsequently, the deployment can be started using the context menu command Deploy of the EAI project in Solution Explorer. In the course of another deployment it has to be noted that existing elements in the cloud must be overwritten. The advancement of this process can be witnessed via the output window.

Sending Data to a Bridge

Once deployment has been completed, the bridge is available via HTTP and can be contacted via REST and SOAP 1.1 and 1.2. The address to be used is made up of the name of the Azure namespace and the address which has been configured for the bridge. Listing 2 shows a WCF configuration which defines that a service client must send messages to a bridge. In this case, wsHttpBinding is used. Alternatively, basicHttpBinding could have been used. However, it has been noted that problems can occur in connection with this binding in the current CTP when messages are enriched.

An SWT token issued by Azure Access Control is to be assigned to enable login. However, as this is not supported by WCF, the clientCredentialType property has been set as None. Instead the SWT token is requested directly in the code and annexed to the service request. To protect this SWT token, Azure Service Bus requires the use of transport security (SSL).

                <security mode="Transport">
                    <transport clientCredentialType="None" />

        <endpoint address="https://steyer-edi.servicebus"
            binding="wsHttpBinding" contract="OrderService

The AccessControlClient class which is attached to this article and is based on Microsoft examples can be used to request the SWT token (Listing 3). The namespace of Azure Service Bus as well as the URL at which Access Control can be found is to be provided to the constructor. The namespace is derived from the previously created namespace, including the ending "-sb". The URL is given in the Management Portal in the namespace property section.

The GetACSToken method is used to request the SWT token. Here the username and a password as well as a scope are to be entered. The first two refer either to the owner of the created namespace or to an appropriate authorised user created within Access Control. The scope defines the scope of validity of the token. As the token is used for access to the service bus within the created namespace, the URL of the service bus including the namespace are to be given as a subdomain.

The SWT token which has been obtained in this way is to be included as an HTTP header in the service request message which sends the desired SOAP message to the bridge. Therefore, an OperationContextScope is created and the token is entered in the list WebOperationContext.Current.OutgoingRequest.Headers which contains the outgoing headers using the SetSimpleWebToken method.

Before data is sent to the local recipient via the bridge, the recipient must be configured in order to be accessible via the service bus using relaying. This procedure will be discussed in the following section.

const string serviceNamespace = "steyer-edi-sb";
const string acsUrl = "";
const string scope = "";
const string username = "owner";
const string key = "...Your Key...";


var acc = new AccessControlClient(serviceNamespace, acsUrl);
var token = acc.GetACSToken(username, key, scope);
Order o = (Order) this.orderBindingSource.Current;
OrderServiceClient proxy = new OrderServiceClient();
    using (new OperationContextScope(proxy.InnerChannel))
        if (!chkCancellation.Checked)
            var ok = proxy.RequestOrderCancellation(o);
            MessageBox.Show("" + ok);
catch (Exception ex)
    MessageBox.Show("Fehler: " + ex.Message);

Making the Local Service Available Via Relay Binding

For the local service to address the service bus in order to be accessible via the service bus, its configuration also has to be adapted. The configuration in Listing 4, for example, contains the full address via which the service bus should make the service available. Moreover, it refers to the basicHttpRelayBinding. Further below, in the transportClientEndpointBehavior section it also contains the username and password with which the service should register with the service bus. The credentials of the namespace owner which are used here for simplification reasons are given in the Azure Management Console in the namespace properties. Alternatively, more authorised users can be created using Azure Access Control.

For the relay bindings and the related configuration entries in the service project to be accessible, the Microsoft.ServiceBus assembly must be linked in. Ideally, it is included using NuGet [REF-4] with the advantage that the required configuration extensions are registered automatically.

For the service to be available via the service bus, it must be activated. To allow the system to be operational, IIS should be used combined with the Autostart option. For the test mode, opening the appropriate svc file directly via the browser after the web application has been started is sufficient. Later, routing and transforming should be possible via the service bus.

<?xml version="1.0" encoding="utf-8"?>
      <service name="ProcurementServiceB.OrderService">
          contract="ProcurementServiceB.IOrderService" />
          <serviceMetadata httpGetEnabled="true" />
          <serviceDebug includeExceptionDetailInFaults="true" />
          <serviceRegistrySettings discoveryMode="Public" />
          <transportClientEndpointBehavior credentialType="SharedSecret">
              <sharedSecret issuerName="owner"
		issuerSecret="{Ihr Key}" />


The second article in this two-part series goes over the following topics: enriching data in a bridge, enriching data in maps, EDI and communication via flat files with the TPM Portal, support for flat files, using the Flat File Schema Wizard, retrieving data via FTP, tracking, importing XML schemas from WSDL, and the conclusion to this article.


[REF-1] Azure Service Bus CTP

[REF-2] Labs Portal,;=17691

[REF-3] TPM-Portal

[REF-4] NuGet,

[REF-5] LOB-Adapter