|When trying to send a message to multiple request response ports you can receive the following error in BizTalk:
The message found multiple request response subscriptions. A message can only be routed to a single request response subscription.
|First of all, you’ll need to reconsider if it’s architecturally sound to route a message to two request response ports? if yes, read further
hot fix available at location http://support.microsoft.com/kb/923632
1) Inside the BizTalk administration console open the BizTalk Settings Dashboard
2) Go to the tab for the hosts settings, and select the host used by the request response ports.
3) Check the checkbox for property Allow Multiple Responses
In a previous post I wrote about an AS2 problem that I encountered after renaming the BizTalk Groupname.
In this post I digg into another AS2 problem, this time related to context properties.
Lately I have been asked to reconfigure an AS2 configuration to send messages with a predefined filename. This is easily done by selecting Transmit file name in MIME header. This checkbox can be found under the AS2 properties of the sending party. As you can see in the printscreen there is a possibility to point to a context property of which the value will be used as filename.
Simply put the context property shortname between two percent signs. If the context property wouldn’t exist you can choose to suspend the message.
After my first attempt to send a message another AS2 error showed up.
A message sent to adapter “HTTP” on send port “sp_As2ToACC” with URI “http://192.168.254.163:5081/BTSHTTPReceive.dll”
” is suspended. Error details: There was a failure executing the send pipeline: “Microsoft.BizTalk.EdiInt.DefaultPipelines.AS2Send, Microsoft.BizTalk.Edi.EdiIntPipelines, Version=18.104.22.168, Culture=neutral, PublicKeyToken=31bf3856ad364e35” Source: “AS2 encoder” Send Port: “sp_As2ToACC” URI: http://192.168.254.163:5081/BTSHTTPReceive.dll
Reason: The type initializer for ‘Microsoft.BizTalk.AS2.Pipelines.BizTalkPropertyList’ threw an exception.
Following the errormessage something went wrong with the initialisation of the BizTalkPropertyList.
This list can be found in the BizTalkMgmt database table bt_DocumentSpec.
The AS2 encoder will query this table to look up the property configured for retrieving the filename.
So what happened? If we open this table we see a lot of columns. But for the AS2 encoder only two seems to matter: clr_namespace and schema_root_name. The error mentioned above is caused when there are two or more property schemes deployed with the same value for these fields. In other words to avoid the AS2 encoder error, the concatenation of these fields must act as a primary key within this table. Also note that the duplicate property does not necessarely have a relation to the configured filename property. Lets have a closer look. Every BizTalk developer knows that every scheme must be made unique by its targetnamespace and rootname. This garantuees that BizTalk will process every message correctly. In the bt_DocumentSpec table this value is stored as ‘msgtype’. In this case we are talking about propertyschemes. So the msgtype field value is constructed by targetnamespace#propertyname. Because a scheme lives in a .Net BizTalk Assembly there is also another .NET namespace associated with the property. Right! clr.namespace.schema_root_name. Do remember that while this is not the fully qualified name of the property it is the value where the AS2 encoder will look for.
For example, the two rows shown in the picture below will cause the error.
I wrote a sql script to easily find duplicates in the bt_DocumentSpec table.
SELECT clr_namespace + ‘.’ + schema_root_name as shortName, COUNT(*)
WHERE xsd_type <> ”
GROUP BY clr_namespace + ‘.’ + schema_root_name
HAVING COUNT(*) > 1
If you find duplicate properties you have to rename the clr_namespace. Do this by opening the propertylist of the propertyschema you want to modify (from within visual studio). There you will find the .Net namespace. Try to keep this namespace unique for all your BizTalk projects.
Last week I was working on an AS2 configuration on BizTalk 2009.
The AS2 messages needed to be encrypted and signed.
Previously I went through an AS2 configuration upon BizTalk 2006 and as I expected everything looked familiar to me.
Setting up the encryption was an easy job. Nevertheless, the second requirement, message signing, wasn’t as straightforward as I hoped.
After configuring and enabling a certificate to sign the messages, I received the following error:
“Error: The Signing Certificate has not been configured for AS2 party.”
I checked and double checked every known issue that i could bing. As there are…
Install the certificate used for signing in the personal certificate store of the appropriate BizTalk host service account.
This installation has to be done while you are logged on with this service account. Otherwise the certificate will be imported in the wrong personal store.
Avoid enabling strong private key protection in the certificate during import in the personal store.
And be sure that the certificate has the private key included.
None of these well known problems solved my error. Searching for new inspiration I repeated the installation on a clean standalone development machine. And yes, here I got more success! The signing and encryption both worked. After comparing the two installations I didn’t find any difference in the configuration of the necessary certificates. So if my AS2 configuration is the same then what makes the difference?
An SQL Trace brought the answer. I asked the dba to capture the SQL activity while BizTalk was trying to send an AS2 message. In the trace we found the following sql-statement:
declare @p3 nvarchar(256)
declare @p4 nvarchar(256)
select @p3, @p4
This statement wouldn’t have looked wrong to me, if I wouldn’t have changed the name of the BizTalk group.
Because most of the time I maintain different biztalkgroups from one BizTalk administration console.
I rename the different BizTalk groups for easy recognition (Dev. group, Acc. Group and Prod. group).
In the above statement we see that the default groupname “BizTalk Group” is still being used. Hence, no certificate
can be found. On my clean development machine the installation succeeded because I didn’t changed the groupname.
After renaming the groupname back to “BizTalk Group” the problem was solved.
This means that the AS2 pipeline component is using the default groupname “BizTalk Group” hardcoded to search for the signing certificate.
And therefore you cannot rename the BizTalk groupname if you want to make use of AS2 with message signing enabled.
This article will give a short and easy explanation on how to use the WCF-Oracle adapter to retrieve a result set from an Oracle database.
The first thing we need to have on the Oracle database is a stored procedure that returns an object of the type ref-cursor.
This article will give some examples on how to program them. The second thing we need to do is to install an oracle client.
This has to be done so we can add an oracle service that can connect to the database, this service will be used later on to retrieve the metadata.
Installing the client will also add the necessary oracle drivers. In this example we added the service Oracleblog with the right settings for our database.
Now we can start developing.
The first step of the development is to generate the metadata and the request-response schemas.
We start by creating a BizTalk project in Visual Studio. After having created the project, we right-click the project and choose “add generated item”. Now we choose “Consume Adapter Service” to start the wizard. This new wizard was added in Visual Studio by installing the WCF-Oracle adapter.
In the wizard we first choose OracleDBBinding for “Select a binding” then we click “configure” to configure the database settings. The first thing we do is adding the name of the service we created in the oracleclient in the field DataSourceName on the pane URI. After this we can add the required credentials. Now making the connection by clicking “connect” will show all the databases available. We have to find the right stored procedure and add this to your BizTalk project. In our example we added the stored procedure P_SEARCH.
Adding it to your project will give you two things:
The request-response schema
The binding file for your send port
In this example two schemas are generated, this is because one schema is referring to the other. Both request and response schemas are created in the same XSD-file. Now we can create a simple orchestration in which we make a mapping to the request schema and create a request-response port so we can send the request and receive the file with the record set.
Now we deploy the project to add the orchestration to the BizTalk server. The next thing we do is creating the proper send-receive port for sending to the oracle database. We do this by importing the binding file that was generated with the schemas in to our BizTalk application. This will create the send-receive port with the correct action- and database settings. We now make a file receive and send port and bind this to our orchestration.
We are now ready to send the message.