wiki

Codit Wiki

Loading information... Please wait.

Codit Blog

Posted on Sunday, December 15, 2013 5:34 PM

Sam Vanhoutte by Sam Vanhoutte

This blog post describes the new testing and debug capabilities through the BizTalk Service explorer

Introduction

The BizTalk product team has recently published BizTalk Service Explorer to the Visual Studio Gallery.  It can be downloaded by clicking this link.  The tool is still an alpha version and will keep being improved over time.    This explorer adds a node to Visual Studio Server Explorer through which a BizTalk Service can be managed.  The following capabilities are available:

  • Browsing of all artifacts (endpoints, bridges, schemas, assemblies, transformations, certificates…)
  • See tracked events of bridges
  • Upload and download artifacts
  • Start & stop endpoints
  • Restarting the services
  • Testing and debugging bridges

Testing capabilities

This blog post will be about that last feature, the testing and debugging of bridges.  With the tool, it’s much easier to test bridges and to get insight in the actual processing and the state of messages at the various stages.  It is not (yet?) possible to have step through debugging of custom code.

Sending test messages

Where we were making our own testing tools, or we used the MessageSender console app, we can now have integrate testing capabilities in Visual Studio.  To do this, you can just right click a bridge and send a test message to it.

sendtestmsg

After doing so, you get a simple dialog box where you can have your bridge tested.

test

Debugging bridges

This feature is very neat.  Here you can proceed step by step through a BizTalk bridge and see how the message and the context changes from stage to stage.

How it works? Through service bus relay!

  • First of all, you have to configure a service bus namespace with the right credentials.  This service bus namespace can be an existing.  Configuring this can be done on the properties of the service node:
    sbname
  • Now this is done, the explorer will start up a service bus relayed web service that will be called from the actual runtime. 

Debug a bridge

To debug a bridge, you just have to right click it and select the debug option.  This will open a new window, as depicted below.  When stepping through the pipeline, the message and the context of the current and the previous stage are visible side by side, so that it can easily be compared.  This is ideal for seeing the mapping results, effects of custom message inspectors and responses of LOB systems…

debug

Be aware that, when a bridge is in debug mode, messages from other consumers can also be reflected and visualized in the tool.  (I tested this by sending a message through the tool and by sending another one outside of Visual Studio)  So, don’t use this on bridges in production!

Feedback for next versions

This tool really makes it more productive and intuitive to test bridges and the behavior of BizTalk Services.  I really hope it will continue to evolve and therefore I want to give some feedback here:

  • I would love to see the HTTP header values in the test or debug tool. 
  • For bridge debugging, it would be nice to right click a stage and to specify something like : ‘continue to here’.  This would make it even faster to test.
  • The tracking of events should be better visualized.  Instead of showing just a list of Guids, I would love to see timestamps at least and I would love to see the tracked items in a better format
  • It would also be nice if you could link one (or more?) test files with a specific bridge in the explorer.  Then it would be faster to test.  Another nice to have would be to drag my test message onto the bridge node to open the test or debug window, pre filled with the dropped file.

 

Sam Vanhoutte

Categories: BizTalk
written by: Sam Vanhoutte

Posted on Monday, June 3, 2013 4:20 PM

Sam Vanhoutte by Sam Vanhoutte

Message itineraries and XML bridges are the most important concepts in the architecture of the Windows Azure BizTalk Services; That's why the first blog post in the WABS series is about these bridges.

In this second blog post on Windows Azure BizTalk Services, we dive a little bit deeper in a concept that is very important for our Codit Integration Cloud project.  All our message processing and integration capabilities is running over bridges. 

This post is not a step-by-step demo walkthrough (Richard Seroter just did a nice one on his blog).  This article intends however to describe some patterns and some architectural explanation.

Itinerary routing mechanism

A message itinerary is a definition of a flow (it was called the flow designer in the past).  Let’s take the following example of a more complex itinerary:

image

The arrows specify the path that a message can follow.  It is a visual flow representation that links different components together. 

Persistence of itineraries

An itinerary does not have any persistence points and executes 100% in memory.  (example: If an FTP destination in an itinerary is unavailable, then there are no retries or whatsoever.  the consumer will get a 500 exception in that case!)

First match unicast routing

There is no one-to-many routing in itineraries.  Routing always happens on the first-matching path!  At every connection point, the message checks the first connection (based on the Sequence Number).  If the condition on that link matches, the message will be routed over that connection and all the other connections are ignored. 

The sequence number gets defined automatically, based on the sequence of adding the connections.

If you want to change the Sequence Number, you need to select the bridge and then you can configure the routing table with sequences in the Route Ordering Table:

image

Implement multi-cast routing

Multi-cast routing is routing a message, so that one message can be routed to multiple (or none) destinations.  If this needs to be implemented, then it is needed to use a service bus Topic with multiple subscriptions.  However, there is a problem, because at this moment, there is no service bus messaging listener implemented yet (like an FTP listener, but on a service bus queue or subscription).

No matching subscription

When a message is not able to arrive on an actual destination node, then the client will get a 500 error from the bridge and in the tracking data, there will be an error with the following description: “No Filter matched for the message.”.

Different bridge types

After we discussed the message itinerary, we can have a look at the bridges in detail.

image

As you can see in the screenshot above, there are different types of bridges:

  • XML One-Way bridge: this is a bridge that processes incoming messages and passes them on to the next matching connection.
  • XML Request-Reply bridge: this is a bridge that processes incoming messages and their corresponding response message.
  • PassThrough bridge: this is a bridge that does not look at the message details and can parse every type of message.
  • EDI bridge: unfortunately, this bridge is not available to the Visual Studio designer and is shielded by the TPM portal.

I would have loved to see a PassThrough Request-Reply bridge and a customizable EDI bridge.  These are not part of this release, but I’m sure they will come in a future release.  (that is the advantage of a cloud service – it’s much easier to add functionality for Microsoft now)

The different stages of a bridge

A bridge (much like a BizTalk pipeline) has different stages.  Depending on the type of bridge, one or more stages can be missing for that bridge.  The first thing to know is that you can easily disable a stage in the property window.  (that is something you typically do when disabling schema validation, for example).  Below, you can see a screenshot of a Request-Reply bridge.

image

Message types

(only in XML bridges)

The first step in an XML bridge is the section where all accepted message types are being defined.  This is done by adding schemas from a project to the request or response (in a Request-Reply bridge) direction.

Important to know:

  • You can add multiple schemas to this section.  The schema that matches the incoming message will be chosen.
  • The schemas you add have to be part of the current project and can not be added from a referenced project.  This is something that hopefully will change shortly.  (we want to reuse schemas and not redefine them in every single project)

image

Decode stage

(only in One-Way XML bridge)

The decode stage will be used if the incoming message is a flat file schema.  Incoming messages will then be serialized to XML, using the flat file schema schema.  This schema contains all the annotations that the Flat File parser will use to create XML out of the incoming flat file message.

Important to know:

  • You can also add flat file schemas in a One-Way bridge (not in an Request-Reply bridge!)  This makes it difficult to provide flat file parsing as a service.
  • The flat file schemas (and the Flat File Schema editor extension) are exactly the same as in BizTalk Server.  This makes it very easy to move flat file parsing between BizTalk Server and Services.

Validate stage

(only in XML bridges)

The validate stage validates the message at that time against the schema that is assigned to it.  The validation can be easily disabled, by disabling this stage (Is Enabled property).

On the validate step, you can specify how warnings should be handled.

Enrich stage

(available in all bridges)

This stage allows to configure property promotion.  All properties can be defined here and can be extracted from the incoming message or the context of the bridge.  There are different locations where this stage gets executed (before / after mapping , request / reply direction)
To configure the stage, the property definitions window should be used.

image

Property values can be read from the following sources:

SOAP Action, MessageId, To, ReplyTo
HTTP Here the name of an incoming HTTP header can be extracted and promoted to the property
FTP FileName, ServerAddress, Folder
SFTP FileName, ServerAddress, Folder
System The following properties can be retrieved from the system context: RequestId (Guid), MessageReceivedTime (UTC time), SourceName, SourceType (Http, Ftp…)
XPath Here an xpath statement (of the long type) should be entered and the schema has to be selected.  If the incoming message matches that schema, the lookup value will be done and promoted.  If the Xpath is not found, the property does not get promoted.
Lookup Here, it is possible to do a SQL Azure database lookup and promote the result of the query to a configured property.  All the database configuration settings are stored in the LookupProviderConfigurations.xml file.
The following screenshot shows the configuration settings for this:
image

Important to know:

  • If a source property does not exist (for example: Ftp FileName in a Http bridge), there is no error raised, the property just does not get promoted (which is good)
  • With the Lookup configuration, it is not possible to provide multiple input fields to a table (as we do with our framework)

Transform stage

(only in XML bridges)

The transform stage allows to configure one or more mappings that will be executed against the incoming message.  The mappings and mapper will be discussed in a later post.

Important to know:

  • You can only select a mapping that matches with the schema, configured for that direction of the bridge.  In the receive side, only mappings with a source schema that matches the request schema will be enabled for selection.  In the reply side, only mappings with a destination schema that matches the response schema are enabled for selection.
  • You cannot select multiple mappings with the same source schema in one transformation selection.  In that case you get the compilation warning: “Two or more maps selected in the Request Transform stage have the same source message type.”.

image

Send reply stage

(only in XML Request-Reply bridges)

In the Send reply stage, it is possible to read message properties and write them to the specific destination protocol (like Soap or HTTP headers).  Message properties can be written to Http or Soap headers of the response.

Important to know:

  • Only properties that have been declared in the Enrich stages are visible here.  If you have promoted a property in a custom bridge component, it is not visible here.  To promoting custom bridge properties, it is needed to define them in an enrich stage first (and fill them with the Tracking Id, for example). 
  • When the destination of an itinerary is a Service Bus messaging entity, the promoted properties are automatically being written on the BrokeredMessage, there is no specific action needed to do this.

image

Encode stage

(only in XML One-Way bridges)

In the Encode stage, the flat file schema will be interpreted to convert the XML document to the flat file structure, if the message matches a Flat File schema.

Expose a pipeline as a service

You cannot deploy a Request-Reply bridge without connecting it to a destination endpoint.  (or you would get the compilation warning: “Bridge '<bridge>' needs to route to at least one connected entity.”).  That means you need to route it to a TwoWay destination endpoint (like a TwoWay External service endpoint). 

But when you just want to create a ‘pipeline as a service’, for example to provide transformation or property promotion as a service endpoint, you don’t want to route to an external service endpoint, because this would cause increased latency.

Luckily enough there is the possibility to use custom WCF bindings and update the configuration of the TwoWay endpoint to that custom binding.  And when you use the EchoMessageBinding that comes with the Samples in the SDK, the request message just gets returned as the response message to the bridge. 

How to configure the EchoMessageBinding

  • Add a TwoWay external service endpoint destination to the designer canvas.
  • Give it a friendly entity name (for example: LoopbackEP).
  • Add a reference to your project to the EchoMessageBinding

Update the LoopbackEP.config configuration file as the following:

<?xml version="1.0" encoding="utf-8" ?> 
<configuration> 
  <system.serviceModel> 
    <extensions> 
      <bindingElementExtensions> 
        <add name="EchoMessageBindingElement" type="EchoMessageBinding.EchoMessageTransportElement, EchoMessageBinding, Version=1.0.0.0, Culture=neutral, PublicKeyToken=d39b54ec599a4cea"/> 
      </bindingElementExtensions> 
    </extensions> 
    <bindings> 
      <customBinding> 
        <binding name="EchoMessageBindingElement" > 
          <EchoMessageBindingElement /> 
        </binding> 
      </customBinding> 
    </bindings> 
    <client> 
      <!-- The clear below makes sure any client endpoints defined in machine.config don't get added--> 
      <clear /> 
      <endpoint name="TwoWayExternalServiceEndpointReference1" address="http://TwoWayExternalServiceEndpointReference2" binding="basicHttpBinding" contract="System.ServiceModel.Routing.IRequestReplyRouter"/> 
      <endpoint name="LoopbackEP" address="http://EchoMessage" binding="customBinding" bindingConfiguration="EchoMessageBindingElement" 
        contract="System.ServiceModel.Routing.IRequestReplyRouter" /> 
    </client> 
  </system.serviceModel> 
</configuration>

Then make sure the destination is using the LoopbackEP endpoint and you’re all set.

 

Unfortunately, it is not possible to expose Flat File parsing as a service at this point in time, because there are no decode / encode stages in Request-Reply bridges.

Some things you might now know about bridges

You can have multiple bridges as source for an itinerary. 

Every bridge has a specific URI.  So this means that a Message Itinerary can have multiple public endpoint URI’s.

With the following example itinerary, there are 3 public HTTP endpoints that can be called separately from each other.

image

The following itinerary has multiple source bridges available.  Based on the source, other ‘pre processing’ logic can be defined.

image

You can have custom code in bridges

It is possible to configure custom components in bridges.  These are being described in a future blog post.  A component can be configured on a stage in a On Enter and On Exit event.

 

Sam Vanhoutte

Categories: BizTalk
written by: Sam Vanhoutte

Posted on Monday, June 3, 2013 4:10 PM

Sam Vanhoutte by Sam Vanhoutte

You may have noticed it. There is a new Windows Azure Service released on the Windows Azure portal: Windows Azure BizTalk Services. This blog posts helps you getting started.

It explains the different steps you need to take in order to get you up and ready to begin development.

You may have noticed it.  There is a new Windows Azure Service released on the Windows Azure portal: Windows Azure BizTalk Services.  This blog posts helps you getting started.

It explains the different steps you need to take in order to get you up and ready to begin development.

The official tutorials are to be found online: here.

 

Get the SDK


To download the SDK, adapter service and other items, you can go to this link.  There you can download the following items for the Windows Azure BizTalk Services preview:

  • BizTalk Adapter Service x64
  • BizTalk Adapter Service x86
  • BTMMigrationTool (this is to migrate BizTalk mappings to the new mapper)
  • MicrosoftEdiXsdTemplates (all X12/EDI schemas)
  • WindowsAzureBizTalkServices SDK

Once you have everything installed, your local machine is ready for WABS development

 

Register for the Windows Azure BizTalk Services preview


You should go to the Azure account portal and log on with your Microsoft account, linked with the subscription that you want to get registered for WABS.  On the portal, select the Preview Features button and you can register for the BizTalk Services preview.  After a while (depending on the available preview slots), you can be allowed to the program.

image

 

Create a BizTalk Service


Once you are registered and allowed to the preview program, you can go to the management portal and create a BizTalk Service

It is not a trivial process, so here you have some tips and a step by step guide:

Step 1: go to the BizTalk Services tab

Click on the BizTalk Services tab and you will be able to click the ‘Create a BizTalk Service’ link.

image

Step 2: specify your service settings

In the first step of the wizard, you’ll have to specify some settings:

  • BizTalk Service name: the prefix to the .biztalk.windows.net that will be used for your service DNS
  • Edition: the specific edition you will chose.  Important! : the edition influences your costs, so be aware of this.  The details on the editions will be discussed later on.  Developer is the one you should use for all your PoC / play ground
  • Region: the data center where your services will be running
  • Tracking database: this is a database on your own server that will be used for all tracking information!  This database can be used for your own tracking queries.  You can add it on a new server, or an existing server.
    It is strongly advised to run the database in the same data center as your service!
  • Subscription: the subscription where you will deploy your service.

image

Step 3: Database settings

In the database settings, you can provide a new database, or link to an existing one.  Here you need to specify some settings, based on your selection.

image

Step 4: Access Control namespace and monitoring settings

Here it becomes tricky.  You need to specify an ACS namespace that will be used to create items in, by the Windows Azure BizTalk Service account. 

image

When creating a new namespace, you will have to do this through the Active Directory tab and create an ACS namespace there. 

  • To get the user and password settings, you need to click on the Manage button in the Access Control Namespace section of the Active Directory module in the Azure portal.  This will bring you to the ‘old’ ACS management portal where you can get your user.
  • This should be done by selecting the ‘Management Service’ link on the left.
  • Then either use the existing ManagementClient service account or create a new one
  • Click the service account you want to use and then click the Password link.
  • To get the password, you can click the Show Password button.
    image

The user name is the name of the service account.

Step 5: SSL Certificate

In the last step before creation, you need to upload the private key of an SSL certificate (pfx) that is linked with your DNS. 

You can change this later and use a self-signed cert for now, by executing the following in the developer command prompt:

makecert -pe -r -n "CN=<yourservicename>.biztalk.windows.net" -e "01/01/2015" -ss my

After doing this, you can export your PFX from your certificate store and upload it here.

 

Step 6: Be patient

Once you click create, it can take up to 30 minutes to have your service generated.

image

 

Step 7: Register the service on the ‘Silverlight’ portal

And just when you thought everything was finished, then you have to register your service in the BizTalk management portal.  This portal is a Silverlight portal that is there during the preview. 

Click on the Manage button and you will be taken to the Silverlight portal

image

On this portal, you have to specify three settings:

  • BizTalk Service: the name of the BizTalk Service you specified in the first step
  • Issuer name: the name of an ACS user that belongs to your ACS namepsace
  • Issuer secret: the shared secret key of that user

image

More blog posts coming soon


As a launch partner, we have been working with Windows Azure BizTalk Services for more than a year now and we have prepared a number of blog posts.  In the coming days there will be blog posts on the architecture and features of this brand new service.

Stay tuned!

Sam Vanhoutte

Categories: BizTalk
written by: Sam Vanhoutte
7 comments

Posted on Monday, June 3, 2013 4:00 PM

Sam Vanhoutte by Sam Vanhoutte

Windows Azure BizTalk Services has been announced today. This post describes some of the concepts and high level capabilities of this integration service. Codit has been working with this technology for more than a year now and some blog posts will follow with details on the different aspects.

Today, Windows Azure BizTalk Services was officially announced on TechEd US.  (more information can be found here: http://blogs.msdn.com/b/windowsazure/archive/2013/06/03/announcing-new-offers-and-services-on-windows-azure.aspx and on the BizTalk blog soon: http://blogs.msdn.com/b/biztalk_server_team_blog/)  From now on, a real preview is available through the Windows Azure portal of these new capabilities.

Codit is one of the few world wide launch partners for this service and we have been actively working together with the product team for more than a year now.  With our online integration platform: Codit Integration Cloud, we are actively extending Windows Azure BizTalk Services (WABS) and are adding value for our customers.  At this moment, we are already live on Windows Azure BizTalk Services.

Over the coming days, a set of blog posts will be posted to dive a little more deeper in these new services:

  • Windows Azure BizTalk Bridges
  • Building Custom pipeline components for Windows Azure BizTalk Bridges
  • Windows Azure BizTalk Adapter Service
  • Windows Azure BizTalk Mapper
  • Windows Azure BizTalk Trading partner management

Stay tuned!

This first post gives a high level overview of the different components that are part of this release.

Bridges & Message itineraries

One of the most important concepts are Bridges (mostly XML bridges).  These can best be compared with BizTalk pipelines.  Bridges are always deployed in a Message itinerary.  An itinerary can be activated through an bridge or through a configured sources (like an FTP/SFTP location).  A bridge can perform the typical messaging/pipeline logic that we know from BizTalk Server: transformation, parsing (flat file and EDI support), property promotion, validation…).

The output of a bridge can then be sent to anther bridge or a destination, like a service bus queue/topic or relay endpoint.

Windows Azure BizTalk adapter service

It is perfectly possible to combine BizTalk Services from the cloud with a BizTalk Server on premises.  But for a lot of scenarios or customers, it is well possible that there is no BizTalk Server installed locally.  If these customers however want to have the possibility to expose some of their on premises systems or LOB applications to a bridge, they can leverage the Windows Azure BizTalk Adapter service.

This IIS-hosted service exposes local endpoints from the WCF LOB adapter pack to the cloud, using the Azure Service Bus Relay bindings.  The nice thing is that it is perfectly integrated with the EAI bridges and the designer, so you can easily drop local endpoints to the canvas and generate their corresponding schemas in the project.

 

The following schema depicts the two biggest EAI parts of this release: a Bridge (cloud) with the Adapter Service (on premises)

image

Windows Azure BizTalk Services – Trading partner management

This it he full featured EDI and TPM portal that is part of this release.  This component allows to configure Trading partners with all their specific settings.  It is possible to configure everything through the portal and to process X12 and shortly EDIFACT messages, coming from your business partners.

The service support multiple protocols, including AS/2 and Bridge/Service Bus entities.

Expect more blog posts soon! (the next one on bridges in a few minutes)

Sam Vanhoutte

Categories: BizTalk
written by: Sam Vanhoutte

Posted on Thursday, October 3, 2013 4:58 PM

Sam Vanhoutte by Sam Vanhoutte

This blog post gives a feature comparison between Windows Azure BizTalk Services and BizTalk Server.

I have given quite some sessions and presentations recently on Windows Azure BizTalk Services.  We had the opportunity to work together with the product team on WABS as a strategic Launch Partner.  I had a lot of discussions and questions on the technology and a lot of these questions were focused on a comparison with BizTalk Server…

Therefore, I decided to create this blog post, I created a comparison table, much like the comparison tables you can see on consumer web sites (for mobile phones, computers, etc…)

If you need more information or have some feedback, don’t hesitate to contact me.

In the mean time, I also came across the following wiki on msdn, that does a good overview too: click to open

Connectivity & adapters

Some adapters are not applicable in cloud services (File, for example), where others are.  BizTalk Services has a lot of adapters not available.  Custom adapters can only be written through the outbound WCF bindings.

  BizTalk Server BizTalk Services
File Yes No (cloud only)
FTP Yes Yes
SFTP Yes Yes
SOAP Web services Yes Yes
RESTful services Yes, no JSON Yes, no JSON
HTTP Yes HTTP
Email Yes Through custom WCF binding
Outbound only
SQL Yes Through adapter service
SAP Yes Through adapter service
Siebel Yes Through adapter service
Oracle DB Yes Through adapter service
Oracle Apps Yes Through adapter service
SharePoint Yes Through custom WCF binding
Outbound only
MQSeries Yes No
Service Bus Yes Outbound only (Relay + Messaging)
Azure Blob storage Through custom adapter Yes

Core messaging capabilities

The biggest difference here is the routing pattern that is totally different between both products.  More can be read in an earlier post: Windows Azure Bridges & Message Itineraries: an architectural insight.  If you want durable messaging, Service Bus queues/topics are the answer, but the biggest problem is that WABS cannot have subscriptions or queues as sources for bridges.

 

BizTalk Server

BizTalk Services

Durable messaging

Yes, MessageBox

Only through service bus and custom polling

Volatile messaging

No, always persistence

Yes

One-to-many routing

Yes

No, first match routing. Only through service bus topics

Property promotion

Yes

Yes

Retry mechanism

Yes

No

Alternative routing

Yes

No

Failed Message Routing

Yes

No

 

Message processing

We have good feature parity here on these items.  The main thing missing would be JSON support.  For that, we have written a custom component already that supports JSON.

 

BizTalk Server

BizTalk Services

Transformation

Yes

Yes

Schema Validation

Yes

Yes

Property promotion

Yes

Yes

Flat file processing

Yes

Yes

XML processing

Yes

Yes

JSON processing

No

No

Binary processing / routing

Yes

No, maybe in passthrough (to be checked)

EDIFACT processing

Yes

Coming soon

X12 processing

Yes

Yes

Management & deployment experience

In my opinion, this is where the biggest challenge lies for WABS.  Administration and management is really not what we are used with BizTalk Server.  Configuration is very difficult (no binding file concept) and endpoint management is also not that easy to do.

 

BizTalk Server

BizTalk Services

Endpoint management

Yes

Only powershell

View message tracking

Yes

Basic

Deployment portal

Yes

Only powershell, Visual Studio

Auditing of operations

Partial

Partial

Health dashboard

Yes

No

Isolation of processes

Yes (hosts)

No, single tenant

Hierarchy of artifacts

Yes (applications)

No

Trading partner management & EDI

The TPM portal of WABS is really very nice and much friendlier than the BizTalk admin console of BizTalk.  The biggest issue with EDI is the fact that there is no possibility to extend and customize the EDI bridge…

 

BizTalk Server

BizTalk Services

Trading partner management

Yes (Biztalk Admin)

Yes (TPM Portal)

EDI extensibility

Yes

No (only with bridge as destination)

Extensibility

Luckily the product team did good efforts to add extensibility and the usability of custom bridge components should still be evolved well.

 

BizTalk Server

BizTalk Services

Custom pipeline components

Yes

Yes

Custom functoids

Yes

Yes

Custom adapters

Yes

Only outbound WCF

Custom business rules components

Yes

No

Custom workflow components

Yes

No

Security

 

BizTalk Server

BizTalk Services

Role based security in management portal

Yes

No

Endpoint security

Extensive support

Only ACS & FTP security

Added value services

This is really where BizTalk Server leads, compared to WABS.  And for most real solutions, these services are often needed.

 

BizTalk Server

BizTalk Services

Workflow

Yes (orchestrations)

No

Business Rules

Yes

No

Business Activity Monitoring

Yes

No

RFID

Yes

No

UDDI

Yes

No

Categories: BizTalk
written by: Sam Vanhoutte