Powered By Blogger

Tuesday, August 29, 2017

Custom XSLT Vs In-Built Functoids in BizTalk Mapper - Best Practice

Hi There,

After 3 years of extensive experience developing integration applications using BizTalk, I have now come to the point realizing the best practices which should be followed while developing integration solutions. I say this because if you are not following or giving attention to the practices being followed then for sure you are making the code as non-readable or which cannot be easily understood by a new developer - in other words, you are pushing the whole solution towards an utter mess.

Integration solutions are by default complex in nature due to the difference in environment and operations being followed in different systems. To make two system talk to each other, it requires tedious amount of work of transforming/translating the data which the other system can understand.

In these three years of my 'Integration Journey', I have had the opportunity to solve various complex integration problems under the guidance of very smart and experienced professionals - fortunately :) . From day one of starting my career as a BizTalk developer, I have always been taught to follow best practices while developing applications be it a POC,  a new project or an enhancement to an already built solution. 

In this blog I'm going to share my experience of when to go with XSLT or functoids or both.

Custom XSLT and Functoids - A Tale Of Two Sides Of The Same Coin

They both are two sides of the same coin because they both are used to get the same output, it is up to to us which side we should get inclined to. 

To Go With Functoids - My Take :- 

Functoids are inbuilt tools in biztalk mapper which have most of the functions embedded in them just like a xslt function and are used in a graphical manner using links from source file and providing output to the target file.

1. Functoids are easy to use,understand and require no coding,  a new biztalk developer is initially habituated to use functoids.

2. Fuctoids should be used where the mapping scenario is simple and doesn't require the use of too many functoids.

3. It is faster to analyse with functoids of what the map is actually doing, while analyzing an XSLT code is lot more difficult as one has to parse through complete XSLT to understand what it is trying to do.

4.You can get to understand the functionality of a functoid by name while with XSLT function you will have to keep some reference in order to know the name of the funcion to use , for example if you want to concatenate two strings , you will get that by string concatenate functoid while with XSLT you will have to search for the function name which concatenates two strings .. i.e string-concate().

5. In other words , use of functoids comes into picture when you are not proficient with XSLT or when the mapping is not very complex.

To Go With XSLT - My Take :- 

1. XSLT should be used where throughput and performance are the concerns, that again depends on the complexity of the map. A custom XSLT is indeed the right choice for getting high performance.

2. It is better to go with XSLT when there are lot of links or connections required for getting a result because having too many connections between the elements and functoids makes the map complex and hard to read.

3. For case where complex looping is required where we have to loop the target record node with no element to loop with in source file then we should go with XSLT instead of table looping functoid. I found table looping functoid to be complex when we had to map data to more than 5-6 elements because it required maintaining lots of columns/rows and lots of links in order to fetch the data.   

THE FINAL CALL -

Microsoft BizTalk team created functoids to make transformation simple and I bet you will not find such an enhanced and simple to use transformation tool in any other integration platforms, so my take would be to use functoids where there is not much complex set of rules involved in transforming the data but I prefer using both of them i.e. use of functoids on nodes where logic is simple and inline XSLT/XSLT Template in scripting functoid on nodes where mapping the data is complex so ultimately I end up using functoids but some of you may agree that it is actually using both.  :) 

Whatever you use should be clean and readable , this is what I have learnt so far.

These were just my thoughts on best practices to go with while choosing between functoids and XSLT.

HAPPY HOOKING STUFFS !!

---------------------------
Saurav Suman
Senior Analyst @ Accenture










Wednesday, March 29, 2017

Resolving SQL notification error in BizTalk

Hi there,

I was recently working with notification feature in BizTalk and was getting an error from the BTS engine whenever I switched on the receive location.

"The messaging engine failed to add a receive location...."

After going through several articles on MSDN and other forums I realised that the possible cause to the above problem could be due to the following :-

1. SQL broker is not enabled
2. Notification statement is not correctly written.

I checked my database to confirm that the SQL broker is enabled which I found it to be true in my case.



After confirming the above I went through my receive location binding properties to check the notification statement.


Nothing looked wrong at the above setting unless I went through this MSDN site and came across a NOTE which stated that - "You must specifically specify the column names in the statement as shown in this SELECT statement. Also, you must always specify the table name along with the schema name. For example, dbo.Employee."

I went back to the receive location binding property and edited my statement as 'Select ID from dbo.Employee.' . Now when I switched on the receive location , the error was gone and I was now getting the notification message whenever a change was applied on the table.

The lesson learnt from the above issue was that we should always specify the table name along with schema name in a statement.

Regards,
Saurav
BizTalk Developer @ JKT