When using the BizTalk Adapter Pack 2.0/WCF LOB on BizTalk 2009.
Remember with Oracle WCF Adapter to install these before the oracle client :
WCF LOB SDK SP2
BizTalk Adapter Pack 2.0
When configuring the operations in the WCF adapter ensure you fully qualify the operation name that matches the logical orchestration port in the WCF ADAPTER Bindings.
If it does not have this, then you will get errors where an InvalidOperationException will occur.
<Operation Name=”LogicalPortOperationName” Action=”http://Microsoft.LobServices.OracleDB/2007/03/CompositeOperation” />
You can read more here.
Since we use ambient Transactions and Nested transaction for the batch, also ensure the Oracle Microsoft Transaction Services is installed. I use the 64 bit version which runs fine with Biztalk in 32 bit mode. However I have BOTH oracle 32bit and 64 bit client (Oracle Dara Access Components 22.214.171.124.20 or higher, since the 32 bit is needed for Developer Design time work with the ConsumeAdapterService Wizards on the developer box. Use different install paths for 32 bit and 64 bit as well.
HINT: Generate all insert, update, select, delete operations in one go on the ConsumeAdapterService wizard, then you never have namespace clashes if you need the operations later!
Another point is to Update the machine.config if you use a later version of the oracle client on the Development box, else the LOB wizard will not work.
<!-- Add in Machine.Config --> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89b483f429c47342" culture="neutral" /> <bindingRedirect oldVersion="126.96.36.199" newVersion="188.8.131.52"/> </dependentAssembly></assemblyBinding>
Here is some notes on it:
2. Install WCF LOB Adapter SDK SP2 x64.
Ensure you include the TOOLS on the development server.
If you do not install the tool, then Visual Studio dev environment will not have the consume adapter feature!
3. Install BizTalk adapter Pack 2.0 for 2009, both for x86 and x64. Get from MSDN Subscription
4. Install Oracle Data Access Components (ODAC) 184.108.40.206.20 bundled with Oracle Instant Client making sure no other client versions are present before installation. 32 First and then 64 Bit.
Keep the above install path as short as possible
Add to Machine.config in C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG
<!– Add in Machine.Config –>
<assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89b483f429c47342" culture="neutral" />
<bindingRedirect oldVersion="220.127.116.11" newVersion="18.104.22.168"/>
Ensure you choose the correct Software location corresponding to the 64 bit folders. 64 bit is d:\Oracle\11
9. Restart the Machine.
Microsoft ESB Toolkit for BizTalk
I am in disagreement with how Microsoft has bundled and named this toolkit. For one BizTalk is not an ESB it is a message broker. So the toolkit should be renamed. An ESB is something that is 100% distributed with no centralised publisher. An ESB is similar to a PCI Bus, Ethernet or CPU Microprocessor Bus Architecture, where all endpoints participate. If you wanted a pure ESB with BizTalk then all endpoints would be BizTalk, which would never be feasible from a financial perspective. A good example of an ESB would be NServiceBus (http://nservicebus.net/).
I love working with BizTalk, but it should never be abused or sold as an ESB. Perhaps a blog about this in depth at some point when I get a chance will be nice.
It is very dangerous selling BizTalk as an ESB to clients, you putting them down a path that is not going to look pretty in 5 years time. .Net to .Net communication does not need a BizTalk Broker in-between it. BizTalk is ideal for integration services and that’s it.
BizTalk can act as a Integration layer as ONE OF the endpoints in an ESB. If Ethernet or PCI was used a central server to publish/subscribe messages, I can tell you that it would not be a very scalable and reliable system.
It is not only BizTalk that is a culprit for misunderstanding ESB’s all major vendors are in the same boat trying to sell ESB servers like IBM Websphere and Oracle SOA. And I can understand why, centralised = licensing made easy.
Remember a true ESB cannot be touched and pointed at, it is a DISTRIBUTED ARCHITECTURE with each endpoint managing it’s own persistence, any endpoint can just go down when it wants and be turned on when it wants to.