R-ESB another way to use ReST in BizTalk 2013

I would speak about the new ReST adapter in BizTalk Server 2013, this adapter offers the possibility to consume ReST services from BizTalk Server and expose ReST from BizTalk too.
There are some interest articles around these topics the best are:

These great articles of Saravana Kumar

Consuming JSON endpoint with BizTalk 2010 R2 REST WCF-WebHttp adapter
http://blogs.biztalk360.com/consuming-json-endpoint-with-biztalk-2010-r2-rest-wcf-webhttp-adapter/

REST (WCF-WebHttp) adapter in BizTalk Server 2010 R2
http://blogs.biztalk360.com/rest-wcf-webhttp-adapter-in-biztalk-server-2010-r2/

In these articles you’ll see the using of the BizTalk adapter consuming ReST services with Json and CRUD canonical strategies, great articles and great work

Another interest aspect of this adapter is the variable mapping, this is an interest feature that permit to  “map” the message context properties with a value specified in the ReST uri.
There are two great articles of Richard Seroter

Exploring REST Capabilities of BizTalk Server 2013 (Part 1: Exposing REST Endpoints)
http://seroter.wordpress.com/2012/11/12/exploring-rest-capabilities-of-biztalk-server-2013-part-1-exposing-rest-endpoints/

Exploring REST Capabilities of BizTalk Server 2013 (Part 2: Consuming REST Endpoints)
http://seroter.wordpress.com/2012/11/19/exploring-rest-capabilities-of-biztalk-server-2013-part-2-consuming-rest-endpoints/
This is a good feature but has a limit, you cannot use these property because is not promoted, so you can use this to particular aspects of the solution, for example work with message field and message context value.

I want to propose another use of this adapter leveraging one of the ReST feature that I love most, using dynamic ReST uri together the use of the message context property, I want to define a new pattern to drive what the BizTalk ESB must to do using only the Rest uri and property context dinamically, you can expand this idea as you want.
I presented this pattern during the WPC 2012 in Italy, I had more than 50 attendees, many BizTalk expert and WCF developers and all them were very concerned and happy of this idea because you can use this idea not only in a BizTalk solution but in any type of ESB solution.

I define a simple generic ReST port, notice the Url=”/*”, I use the wildchar * to define a generic uri, in this case you can write all you want in the uri.

I defined three type of Convention Over Configuration

The first scenario, the most simple and the Convention Over Configuration is

HTTP://ADDRESS/PROPERTYNAME/PROPERTYVALUE

Where:

PROPERTYNAME
is the name of the context property that must be promoted

PROPERTYVALUE
is the value of the context property

I develop a pipeline component that allows to specify which properties of the message context you want promote specifying the name and the value in the ReST uri, this operation is very simple, see the code below.

note the use of [To] property of http://schemas.microsoft.com/BizTalk/2006/01/Adapters/WCF-properties namespace to rereive the ReST uri.

And I create a property in the component, RESBnamespace, to specify the namespace to be used to promote the properties see pictures below

I created some property schemas to define many properties to use them for a thousand of operations, for example:

HTTP://localhost/orchestration/orchestrationname
To routing a message to particular ESB orchestration

HTTP://localhost/companyX/companyname
To routing a message to a particular send port

This is more simple scenario but we can create more complex conventions

The idea behind is very simple but in the meantime very powerful and the great value of this idea is not simply put a value to a context property but how to use this in a ESB solution.

See this second Convention Over Configuration
HTTP://ADDRESS/OPERATIOTYPE/OPERATIONNAME

And more complex scenarios
HTTP://ADDRESS/OPERATIOTYPE1/OPERATIONNAME2/OPERATIOTYPE1/OPERATIONNAME2/….

Where:

ADDRESS
is the server address for example localhost or myserver.com

OERATIONTYPE
To identify the type of the operation required to ESB

OERATIONNAME
To identify the value associated it.

I defined the operation type and its meaning

MAP         (dynamic mapping)
PRT        (dynamic routing)
SRV        (Service/Orchestration)
SYS        (System/Integration)

At this point I defined a set of properties to map the operations, see below

Below some example
HTTP://localhost/ResbMapping/mapname

This call send a message to BizTalk a make a dynamic transformation  simply using the name of the map deployed in BizTalk Server

To make a dynamic transformation very performable I use the great library of my dear friend, Paolo Salvatori, this library use  the method Transform of the System.Xml.XmlReader, it’s much more efficient than canonical BTS mapping.

You can find the library HERE

To call the transform method you need to use the Map Fully Qualified Name

Link libreria

To get the MFQN I use this query on BizTalk management database

The MFQN is the FullName + “,” +  nvcFullName, in this case will be
RESB.SystemService.Test.dynmap,RESB.SystemService, Version=1.0.0.0, Culture=neutral, PublicKeyToken=bd1931da42be8e78

Naturally, to access to BizTalk management database I take the connection string and build it from registry

I created an orchestration called TransformationResolver.odx, this orchestration is simply subscribe with this subscription
Where ResbMapping exist

This is the orchestration, very simple

Simply, this orchestration receive a general xmldocument message and in the construct message call a map transformation

Other sample call
HTTP://localhost/ResbSystemIntegration/sysname
This is an interest call, in this call the message will be routed to another orchestration, DynamicIntegrationResolver.odx

What does this orchestration, this orchestration receives the message and search a policy in the BizTalk BRE with the name sysname
This rule return all parameters to set the BizTalk dynamic port to send the message to the correct system, for example SAP.

These are simple examples but we can make the scenario more interest, see this composite uri ReST call

HTTP://localhost/ResbMapping/mapname/ResbSystemIntegration/sysname

To resolve this case I created another property ResbOperationOrder I use this property in the case of multiple operations

In this case I set the ResbOperationOrder property as below
ResbMapping/mapname/ResbSystemIntegration

and the message will be send to a orchestration named MultipleOperationResolver.odx, this process split all command and execute all operation in cascade, naturally using the TransformationResolver  and DynamicIntegrationResolver orchestrations in direct routing.

The third Convention Over Configuration that I use is an enrichment to distinguish the subsystem
HTTP://ADDRESS/BINDING/SUBSYSTEM/OPERATIOTYPE/OPERATIONNAME

And naturally

HTTP://ADDRESS/BINDING/SUBSYSTEM/OPERATIOTYPE1/OPERATIONNAME1/OPERATIOTYPE1/OPERATIONNAME1/….

Where

BINDING is TW for two way communication, OW for one way

SUBSYSTEM to identify many operational sub systems

At this moment I using this pattern to make many pattern operations that I have called, ReST Dynamic Routing, ReST Dynamic Mapping and ReST Dynamic Integration and another interest aspect is the possibility to make all of these together in one ReST call.

You can use this idea to create many interest ESB scenarios
I creating a toolkit, the name is R-ESB toolkit, I don’t know when I’ll finish but at this moment there many interest components yet, naturally I will share this in codeplex.

About these ads

One comment

  1. Pingback: BizTalk 2013 and Rest « Connected Pawns

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s