Call SubmitDirect Adapter from Orchestration

If we want call SubmitDirect directly from Orchestration, we will get this error:

"The Messaging Engine failed to register the adapter for "Submit" for the
receive location "submit://submitrequest". Please verify that the receive
location is valid, and that the isolated adapter runs under an account that
has access to the BizTalk databases."

This error is because SubmitDirect adapter needs to run in an Isolated process, because is an Isolated adapter.

My solution is convert this adapter in an In-Process adapter. This is simple, we need to do 2 changes in the SubmitDirect solution:

1) Implement IBTTTransportControl at BizTalkMessaging class (in MessagingAPIs.cs at TransportProxyUtils project), for example:

public void Initialize(IBTTransportProxy transportProxy)
{
_tp = transportProxy;
}

public void Terminate()
{
}

2) Change RegisterAdapter.cs in TransportProxyUtilsReg project:

Change this line "rkBizTalk.SetValue("Constraints", 0x00000081);" with "rkBizTalk.SetValue("Constraints", 0x00000089);"

First change is to implement all interfaces that need an In-Process adapter (see BizTalk documentation "Interfaces for an In-Process Receive Adapter").

Second change is to indicate that our adapter is hosted in-process (see BizTalk documentation "Registering an Adapter -> Constraints -> eProtocolReceiveIsCreatable flag).

With this changes, we build the solution and then, we register our custom SubmitDirect adapter and voilà, we can call SubmitDirect adapter from a Orchestration without errors, because our adapter will run within BizTalk process.

XPath inside BizTalk

XPath is a powerfull feature in BizTalk solutions, but is little complicated when we have a lot of namespaces and elements.

If we develope a solution wich uses this feature, it can be very frustrating, because it's a thorny issue.

There is a good tool that help us to test our xpath expressions, XPathmania.

This tool is a plug-in for Visual Studio 2005 and allows us to do queries against a XML document. After install it, we open this tool in View -> Other Windows -> Xpathmania menu:


If we open a XML document, we can test our xpath queries:


If xpath query is correct, Xpathmania will set the backcolor of selected nodes to green. If it is any sintax error in our query, Xpathmania will tell us the error:

"No XOP Parts"

Due to a bug in Axis2 1.3, when we call a web service from a .NET application using WSE 3.0 and MTOM, we receive this error: "WSE1608: No XOP parts were located in the stream for the specified content-id: ...".

The problem is that in Axis2 response we receive something like this:

HTTP/1.0 200 OK
Date: Sun, 09 Dec 2007 10:41:00 GMT
X-Powered-By: Servlet 2.4; Tomcat-5.0.28/JBoss-3.2.7 (build: CVSTag=JBoss_3_2_7 date=200501280217)
Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_E3F73E4E791CD88AAB1197196860587; type="application/xop+xml"; start="0.urn:uuid:E3F73E4E791CD88AAB1197196860588@apache.org"; start-info="text/xml"
Set-Cookie: BIGipServerhttp_87_integracion= 50571456.22272.0000; path=/
Connection: close

--MIMEBoundaryurn_uuid_E3F73E4E791CD88AAB1197196860587
Content-Type: application/xop+xml; charset=utf-8; type="text/xml"
Content-Transfer-Encoding: binary
Content-ID: <0.urn:uuid:E3F73E4E791CD88AAB1197196860588@apache.org>

The problem is with start attribute, that doesn't match with the content-id of the object root, because it hasn't < and >. According to RFC 2387: "The 'start' parameter, if given, points, via a content-ID, to the
body part that contains the object root.".
A example from this RFC:

Content-Type: Multipart/Related; boundary=example-1
start="<950120.aaCC@XIson.com>";
type="Application/X-FixedRecord"
start-info="-o ps"

Content-Type: Application/X-FixedRecord
Content-ID: <950120.aaCC@XIson.com>

Here is a link to this issue from Axis2:
https://issues.apache.org/jira/browse/AXIS2-3196.
Here is a link to the culprit version change: http://svn.apache.org/viewvc?view=rev&revision=555276.
Here is a link to the correct version change: http://svn.apache.org/viewvc?view=rev&revision=573037.

Here is the .NET call, that is correct according to RFC:

POST /services/SOAPService HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.1433)
VsDebuggerCausalityData: uIDPo/roRa0+I2ZGg8sva4yaNrAAAAAA0oIuYeGHw0WWedV3KmBPQfNgOTYMehBNh8VxIFQqoJ8ACAAA
SOAPAction: "process"
Host: test.host.com
Content-Type: multipart/related; type="application/xop+xml"; boundary=--MIMEBoundary633327972312845535; start="<0.633327972312845535@example.org>"; start-info="text/xml; charset=utf-8"
Content-Length: 1358
Expect: 100-continue
Proxy-Connection: Keep-Alive

----MIMEBoundary633327972312845535
content-id: <0.633327972312845535@example.org>
content-type: application/xop+xml; charset=utf-8; type="text/xml; charset=utf-8"
content-transfer-encoding: binary