BizTalk Development

BizTalk Integration with any Java API.

Vishal — Thu, 02 Jul 2009 15:13:55 GMT

Hello All,

Recently I am engaged in an Integration project in which I have to Integrate BizTalk Server 2006 R2 with EMC Solutions product called Smarts Software. This Smarts Software exposes a Java API and a Web Service interface. Initially knowing that it exposes a Web Service I felt relief and it would make my life easy but then talking with the Smarts Software people they told us that the Web Service Interface is very naïve and it does not have all the functionality we need for the Integration. The only option left was to talk with the Java API. Here I started my research to find the most efficient way to talk with this Java API.

Below are the options:

· Create a Java Web Service which wraps the Java API and BizTalk can consume that WS.

o BizTalk can use SOAP Adapters or WCF-basicHttp Adapter and talk with this Service.

o We need to write code for each of the functionality and every time any change in the Java API need to modify our WS.

o Would require considerable time for development and testing the Java Web Service.

o Always there would be chance for any errors occurring on .NET and Java side.

· Using IKVM

o IKVM.Net is an implementation of Java for Mono and the Microsoft .NET Framework.

o It includes the following components:

A Java Virtual Machine implemented in .NET
A .NET implementation of the Java class libraries
Tools that enable Java and .NET interoperability

o For more information visit: http://www.ikvm.net/

o Once again need considerable time for understanding and start developing.

o More time would require for development. It’s an open source and did not see much people in Industries using this tool so skeptical about its performance and reliability.

o Always chance for any errors occurring on .NET and Java side.

· Using JInegra for .NET

o J-Integra® for .NET is a high performance middleware bridge that enables Java .NET interoperability. Its pure Java implementation of Microsoft's .NET Remoting distributed object wire protocol allows you to access .NET components from Java clients, and Java objects from .NET clients.

o J-Integra® for .NET can be used for point to point integration scenarios where the two application that need to communicate with each other don’t need to plug into a common integration infrastructure such ESB. Example use case scenarios include:

§ .NET client interaction with a J2EE Server

§ .NET client invoking Java desktop application.(Similar of our integration project i.e. .NET client invoking a Java API)

§ .NET Server interaction with a J2EE Server.

§ Java desktop applications invoking .NET Server.

o For more information : http://j-integra.intrinsyc.com/products/net/

o Found out that is it being used by many industries also. The list goes http://j-integra.intrinsyc.com/company/customers.asp.

o Considerably cheaper than other products available in market but little more complex compared to other in respect to implementation.

o So more time required to understand the product and later implement it but definately worth product to look into.

· Using Java Native Interface (JNI)

o JNI is an open standard and is a programming framework that allows Java code running in a Java Virtual Machine (JVM) to call and to be calledby native applications (programs specific to a hardware and operating system platform) and libraries written in other languages, such as C, C++ and assembly.

o Again we need considerable amount of time and effort to learn JNI and code it.

o We need to write code for each of the functionality and perform modifications on our side for any changes on Java API.

o For more information visit: : http://java.sun.com/javase/6/docs/technotes/guides/jni/index.html

· Using CodeMesh JuggerNET

o Similar product like JIntegra for .NET and similar factors for consideration.

o For more information: http://codemesh.com/products/juggernet/index.html

· Using JNBridge Pro

o JNBridge is since long time in Market and is a well known product by many industries (JNBridge Clients) which had done integrations work between .NET and Java.

o JNBridgePro enables you to join anything Java together with anything .NET across the platform boundary.

o First product which actually has an adapter to talk with BizTalk called JMS Adapter for BizTalk Server. Unfortunately that was not for our project as we had to talk directly with the Java API and not a Java Messaging Bus.

o It’s really fast to develop and very easy to generate proxies and also regenerate for any changes in the API.

o For more information visit: http://www.jnbridge.com/jnbpro.htm

I downloaded trial versions of three of the products which were Codemesh JuggerNET, jIntegra for .NET and JNBridge Pro. If you ask my frankly than I was most comfortable with the JNBridge pro. I just saw their one of the demo and within minutes I was able to generate a proxy for the Smarts Java API and reference that in my BizTalk Solution and I was so happy to see that I can just make a variable of any method of the Java API and use it directly in the expression shape. Hence so far it made my life easy. It does has many consideration about how the JNBridge will talk with the actually Java API. It say that there are 3 ways in which it can communicate: Shared Memory (both on same server), IP/TCP and HTTP/HTTPS. So far everything looked good with the JNBridge. Also we can develop a custom adapter using the generate proxy and talk with the Java API.

So I concluded to 2 option in the end.

First is using the JNBridge Pro. (Should fit in out project budget as its considerably costly product than other products.)

Secondly, develop a Java Web Service which sounds very straight forward. ;-)

I will update this post once we decide on what approach we are going to take and how it went.

Thanks,

Vishal

References taken for Wikipedia and mentioned products websites.

Experince of BizTalk and SalesForce.com Integration

Vishal — Fri, 19 Jun 2009 20:23:14 GMT

Hi All,

Recently in my last client engagement I was involved in an Integration project which had Salesforce.com as one of the Enterprise System.

The company was using SFDC as their CRM system. Our team consisted of 3 members. One Salesforce.com guy, me as BizTalk/.Net guy and a core .Net/SQL guy. Our requirement was embed data flow in both direction i.e. from Salesforce.com and company db say “xxx” and from xxx to Salesforce.com. This was to be done in both real-time and scheduled or batch basis.

Initially we did lot of research about SFDC adapter available in market but we just found on company called Two Connect which had developed those adapters. We even spoke with many of the Salesforce.com guys working since years and if they have anytime involved in such a integration project.

Anyways, TwoConnect has pretty decent adapters but few factors due to which we did not use them.

One of them was their cost and was not fitting company budget.

Secondly, when I was in that project MS had released BizTalk 2009 version and the company had BizTalk 2006R2 version and that company may anytime upgrade to 09 version. Then what about the adapter compability with the newer server. May be there would be a patch out and they would tell us to install and all. I was the only BizTalk guy there and me being the contractor, the company did not want to go in such hassle so we did not opt using the TwoConnect SFDC Adapter.

If I go in more details about the TwoConnect SFDC Adapter than it was very straight forward (“looking at their documentation and videos”), similar like you use a SQL Adapter, i.e. Add generated Items and wizard pops up and few configuration parameters, like which methods of the SFDC Apex API you need to call and stuff similar.

Now coming back to the architecture we opted: For the first scenario i.e. data coming from Salesforce.com to xxx (company db), we had a WCF Svc sitting in between xxx and BizTalk. So I consumed the WCF Svc and I had my receive and send ports exposed as Web Svc, which later on the Salesforce.com API consumes. There is huge internet cloud sitting in between and lot of firewalls and IP configuration issues we came up. But eventually resolved.

HLD architecture : Salesforce.com - Apex API - BizTalk - WCF Svc - xxx

(Here Biztalk exposed as WS and Apex API consumes it, initially we had exposed it as a WCF Svc and later on found out that somehow the APEX Api does not like WCF so had to step down on Web Service.)

Next is for the data going from xxx to SFDC, this was a challenge as in order to communicate with SFDC Apex API lot of stuff had to be done dynamically. Also we had time and budget constraints. Simplest BizTalk design is having a master orchestration which talks with the API and later on calling other child orchestrations according to function performed i.e. either update, insert, delete, create etc. Here for the first time BizTalk talks with apex API and it responds back with a URL and BizTalk has to dynamically next time send actually data to this URL so some dynamic bindings we did. And for getting the data from xxx, there was a WCF Svc sitting there BizTalk talks with that svc which is pretty much straight forward.

HLD architecture: xxx – WCF Svc – BizTalk – Apex API – Salesforce.com

(Here BizTalk exposed as WCF Svc and the other WCF Svc talks with endpoint)

One the most quickest option to complete this integration is having 2 WCF svc’s or WS sitting around BizTalk and BizTalk acting just as a pipeline in between. Here we did not do any transformation nor applied any business rules or any other process on the data. Just a pure messaging solution.

So the architecture will be like: XXX – WCF Svc – BizTalk Server – WCF Svc – Apex API – Salesforce.com .

It was a challenge for the data going from xxx to SFDC but was fun though. That was my experience working with Salesforce.com

If you anyone has done integration with SFDC than I would love to hear their experiences.

Thanks,

Vishal Mody

Types Of Convoys

Vishal — Mon, 18 Aug 2008 21:41:57 GMT

Convoys are groups of related messages that are intended by a partner business process to be handled in a specific order within an orchestration.

1 Concurrent Correlated receives

Concurrent correlated receives are correlated receive statements in two or more branches of a Parallel Actions shape. If a correlation is initialized in more than one parallel task, each correlated receive must initialize exactly the same set of correlations. The first such task that receives a correlated message will do the actual initialization, and validation will be done on the others.

2 Sequential Correlated receives.

Sequential correlated receives are receives that are correlated to previous receives. Convoy processing takes place for cases in which the correlation sets for a receive are initialized by another receive.

Taken from Pro BizTalk 2006 (By: George Dunphy and Ahmed Metwally)