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.
