2.This XML message is made available to the WCF SQL Adapter by using the File Adapter

3.The WCF SQL Adapter then pushes this XML message to a preconfigured SSB queue by invoking a Stored Procedure

Create the database artifacts required for the SSB conversation

1.A message type, which denotes the format of the message in the queue

2.A contract, which denotes the conversation between a sender and a receiver and also includes the type of message flowing between them

3.The Initiator & Target queues, where messages are stored

4.The Initiator & Target services, which utilize the above queues

USEmaster;

GO

ALTERDATABASE<your db name here>

SETENABLE_BROKER;

GO

USE<your db name here>;

GO

CREATEMESSAGETYPE

[//SqlAdapterSSBSample/RequestMessage]

VALIDATION=WELL_FORMED_XML;

CREATECONTRACT [//SqlAdapterSSBSample/SampleContract]

([//SqlAdapterSSBSample/RequestMessage]

SENTBYINITIATOR

);

CREATEQUEUE InitiatorQueue1DB;

CREATESERVICE

[//SqlAdapterSSBSample/InitiatorService]

ONQUEUE InitiatorQueue1DB;

CREATEQUEUE TargetQueue1DB;

CREATESERVICE

[//SqlAdapterSSBSample/TargetService]

ONQUEUE TargetQueue1DB

([//SqlAdapterSSBSample/SampleContract]);

5.A stored procedure, say InitiatorSP, that will take the message as an argument and push it to the SSB queue. Let’s use the name RequestMsg for the argument.

SETANSI_NULLSON

GO

SETQUOTED_IDENTIFIERON

GO

CREATEPROCEDURE [dbo].[InitiatorSP]

@RequestMsg xml

AS

BEGIN

DECLARE @DlgHandle UNIQUEIDENTIFIER;

BEGIN DIALOG @DlgHandle

FROMSERVICE

[//SqlAdapterSSBSample/InitiatorService]

TOSERVICE

N'//SqlAdapterSSBSample/TargetService'

ONCONTRACT

[//SqlAdapterSSBSample/SampleContract]

WITHENCRYPTION=OFF;

SENDONCONVERSATION @DlgHandle

MESSAGETYPE

[//SqlAdapterSSBSample/RequestMessage]

(@RequestMsg);

END

GO

Create the BizTalk artifacts

1.Start the BizTalk Server 2009 Administration Console

2.Create a new BizTalk application, say SSBSendApplication

3.Create a new Receive Port, say FileReceivePort and add a new Receive Location, say FileReceive

a.Set the Type to File and configure the Receive Folder to point to a local share, say c:\in

4.Create a new Static One-way Send Port, say SqlSendPort

a.In the General tab,

i.Set the Type to WCF-SQL

ii.Click Configure and set the properties as follows

1.In the General tab, set

a.Address – the format is “mssql://<servername>/<instancename>/<databasename>”. For example, on my machine (using the default instance of SQL server), mssql://localhost//SSBTestDb (where SSBTestDb is the name of my database)

b.Action – the format is “TypedProcedure/<schemaname>/<storedprocedurename>”. For example, in my case, it is TypedProcedure/dbo/InitiatorSP

2.In the Messages tab, select Template and fill in the XML box with the following

For customers currently using the Microsoft BizTalk Adapters for Enterprise Applications (aka the LOB adapters) and willing to migrate their existing projects to the WCF-based LOB adapters, here's a tool that will help you migrate your projects to work with BizTalk Adapter Pack 2.0.

Before we start talking about the tool and the adapter projects it can be used against, let us set the ground by laying the rules for the naming convention that we will be using here:

Microsoft BizTalk Adapters for Enterprise Applications adapters are referred to as n

on-WCF LOB adapters.

Adapters part of BizTalk Adapter Pack 2.0 are referred to as WCF-based LOB adapters.

What does the tool do?

The migration tool accepts BizTalk project/Solution files containing schemas generated by non-WCF LOB adapters and generates corresponding new BizTalk project/solution files having schemas corresponding to the WCF-based LOB adapters, with the maps and orchestrations modified accordingly. This tool helps you to migrate the projects for the following adapters:

Sometimes, the Oracle EBS adapter throws this error while invoking artifacts like Concurrent Programs, Interface Tables, Interface Views and a few PL-SQL APIs.

The message in the event viewer looks like the following (snipped some portions to improve readability):

Event Type: WarningEvent Source: BizTalk Server 2009...

Description:The adapter failed to transmit message going to send port "<your_send_port_name>" with URL "oracleebs://<YourURI>". It will be retransmitted after the retry interval specified for this Send Port.

Details:"Microsoft.ServiceModel.Channels.Common.ConnectionException: Could not retrieve User ID, Responsibility ID, and Application ID. These values are required to set the application context.Make sure that you have specified correct values in the binding properties or the message context properties for setting the application context.

---> Microsoft.ServiceModel.Channels.Common.MetadataException:

---> Oracle.DataAccess.Client.OracleException ORA-01403:

....

at Microsoft.Adapters.OracleEBS.OracleEBSConnection.InitializeApps(...)at Microsoft.Adapters.OracleEBS.OracleEBSConnection.OpenConnection(...)

One of the commonly asked questions is "How do I determine the correct responsibility name to be used?".

Here is a tool that you can use to determine the responsibility that you need to set app context. The tool will prompt will prompt you for relevant details like credentials, application short name etc.

Usage: CheckAppContext [/Responsibility:<Responsibility>]

-If the responsibility name is not provided, the tool lists the valid responsibilities that could be used for the apps user <AppsUserName> in the application <AppsShortName>.

-If the responsibility name is provided, the tool checks whether the provided combination of <AppsShortName> and <Responsibilty> can be used to set app context for the Apps User <AppsUserName>.

NOTE: The responsibility should be enclosed in quotes if it has spaces else quotes are not required .

Here is a simple way to get started on Oracle AQ (Advanced Queuing) using the Oracle Database and/or Oracle E-Business Suite adapters. Here is what I did, right from defining my queue - one step at a time.

A word on dequeue and enqueue functions - these are simplistic in this example. You might want to modify them to take more inputs (for example - more message properties or enqueue/dequeue properties as input). The dequeue function returns immediately if a message is not available for dequeue and returns null in that case. You could tweak that too.

Step 7 - Call the functions using the adapter!It is easy calling these from the adapter now. The reason why the DBMS_AQ.ENQUEUE and DBMS_AQ.DEQUEUE cannot be called directly from the adapter is that they use complex data types that are not supported by ODP.NET. One can now even call the dequeue function in a polling context, and get messages delivered to them as they are pushed into the queue! The links to portions of the Oracle Database adapter help that will help you do this are:

Siebel adapter uses the COM interface to invoke calls on Siebel. For business component query, Siebel supports two ways of retrieving the field values for records. One can either use GetFieldValue to retrieve one field at a time or the other option is to use GetMultipleFieldValues to retrieve values for a bunch of fields in one go. The latter is better from a performance standpoint and is what the adapter uses. The problem with this approach though is that even if one of the fields, whose values are being retrieved, is mis-configured, the entire query call fails.

In development environments, it can happen that some of the customizations have issues, resulting in query failure as described above. The first step towards diagnosing the problem is identification of those problematic fields. The error message doesn’t always help identify the fields. When in such situation, one can use the attached Siebel COM sample code to narrow down the fields. You will need to add a reference to sstchca.dll (present in the Siebel install folder, in the bin sub-directory).

Once you have narrowed down the fields, you can either fix the issue with the field or if it’s not of interest, mark them as inactive on Siebel backend. You can then query using the Siebel adapter without any issues. Alternately, you can also use the QueryFields (optional) argument passed to the query operation to retrieve only the fields of interest.

The BizTalk Adapter Pack 2.0 was released to manufacturing and is now generally available .

For BizTalk 2009 users (except branch edition), the Adapter Pack 2.0 license comes free and can be downloaded from the volume licensing site.

Biztalk 2006 R2 users can get the Biztalk Adapter Pack if they have Software Assurance for Biztalk.

Others will have to buy it seperately.

The prequsite for this is the WCF LOB Adapter SDK SP2. A 120 day evaluation version of the Adapter Pack 2.0 is also now available . The below table summarizes all the links you need to get started with the Adapter Pack 2.0 .

The Forum to ask any questions or look for answers is here . This version also includes the Customer Experience Improvement Program. Do turn it on so that we get some valuable feedback that can be used for future improvements.

I have seen quite a few instances where people run into issues while using the WCF Siebel adapter because of

a.Siebel Web Client is not installed correctly on the machine

b.Or the URI passed to the adapter, that eventually gets transformed to the connection string passed to Siebel, is incorrect

In order to eliminate the above 2 as possible causes, you can try out the following sample code that will use the Siebel COM interface to directly talk with Siebel (adapter is not involved). Please make sure you don’t see any error messages.

/// Application that will issue Login-Logoff request to Siebel

///

/// To run this program,

/// - Set ConnectString, Username and Password. ConnectString is of the format

If you are writing a WCF LOB adapter that can be consumed through BizTalk, you need to be aware of certain issues that can manifest because of the way BizTalk interacts with WCF adapters. Some of these can have performance and scalability impact and hence you should consider them when designing/configuring the adapter.

Processing in IConnection/IConnectionFactory instance – When using SSO, for each message, BizTalk will end up creating a new IConnectionFactory and a new IConnection instance. If your adapter is doing a lot of processing in either of those instances, it can cause significant performance impact. So you will need to think of alternatives – possibly doing the processing upfront and caching.

Caching of LOB artifacts on IConnection instance – Typically you will have some LOB artifacts that will comprise the context associated with an IConnection instance. If your adapter is using WCF LOB Adapter SDK’s connection pooling, in the non SSO scenario, the IConnection instances will be closed only when the idle connection timeout expires. So you need to think about freeing up the LOB resources that comprise your connection context. If you make idle connection timeout too small, it would impact performance since LOB connection creation will incur an overhead and if you keep it at a large value then you will be holding on to LOB artifacts for a longer time than you really need to, possible scalability/performance impact.

Writing/promoting properties to BizTalk message context – When the adapter receives a WCF message from BizTalk, it will have all the properties comprising the BizTalk message context. For messages that originate from the adapter, if you want to have properties either written/promoted to BizTalk message context, you can look at http://technet.microsoft.com/en-us/library/bb246105.aspx on how to go about doing that.

Transaction overhead – BizTalk will by default start a transaction and send the message/process the response in that transaction scope. This can cause a significant overhead particularly if say the LOB doesn’t support transactions. In BizTalk 2009, there is an option on the Send port that lets you configure whether transactions should be enabled or not.

On the website http://msdn.microsoft.com/en-us/library/dd451003.aspx, we have a step by step guide to publish the Siebel adapter as a WCF Service in IIS and then have MOSS consume the data using that service. In this approach, credentials are pass by MOSS to the adapter using custom HTTP headers.

If instead you want to consume this service from a .net application or any client that wants to pass the credentials using the ClientCredentials object, this is how you will go about doing it. Follow the steps on http://msdn.microsoft.com/en-us/library/dd450994.aspx that gives detailed instructions about publishing the WCF service. There are 2 differences though

1.In the “Configure service and endpoint behaviors” page, for “AuthenticationType” you will need to select “ClientCredentialUsernamePassword” (as opposed to “HTTPUsernamePassword” that the tutorial specifies)

2.In the “Configure the service endpoint binding and address” page, click on the BindingConfiguration (the … following BasicHttpBindingElement) to customize the binding. Set Security Mode to “TransportWithMessageCredential”

Follow the rest of the instructions for publishing the service. You can now connect to the service using a .net proxy application and pass the credentials using the ClientCredentials object.