|
Home > Archive > BizTalk Server General > May 2004 > [0x0139] The XML document could not be translated when using Submit in AIC
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[0x0139] The XML document could not be translated when using Submit in AIC
|
|
| belgarion 2004-05-14, 12:55 pm |
| Hi All,
I am trying to do an IInterchange.Submit from inside a VB AIC like so
.....
sSubmissionGUID = oInterchange.Submit(BIZTALK_OPENNESS_TYPE_NOTOPEN, _
sDoc, _
, _
, _
, _
, _
, _
sChannel, _
, _
sEnvelope)
..... and am recieving the following error ...
[0x0139] The XML document could not be translated. The map specified
by reference "http://server/BizTalkServerRepository/Maps/company/Generic_to_INV.xml"
failed. Verify that the map is up to date.
[0x0140] The following channel configuration setting is not valid:
"INV_XML"
.... A document is being mapped multiple times and I need a way to keep
track of progress. I do this by writing the Submission GUIDs returned
from IInterchange.Submit to another database and then use the
Submission GUIDs to pick up document info using the BTSDocTracking
objects.
I know that the document itself and ports, channel, map and doc specs
are completely valid as I've written the file out to disk and had it
picked up by a file recieve function using the same channel and, hey
presto, it all works fine (i.e. the document is processed all the way
to its destination!).
Does anyone know why this occurs? And more imporantly, how to fix it.
(p.s. Using B2002 on an old established site. Is this some sort of
DB/OLEDB problem? Using SQL Server BTW. Ive had a few problems with
IInterchange.Submit causing DB updates in AICs to be completely rolled
back in the development environment.)
| |
| belgarion 2004-05-24, 11:35 pm |
| More info on this one ....
I came across the following KB item:
http://support.microsoft.com/defaul...kb;en-us;332188
The problem in the issue refered to in the KB article that raises
exactly the same 'bogus' error message, seems to be happening in my
situation as well. Unlike the issue in the KB article, I am using a
single machine with BT and SQL installed and using a completely MS
toolset.
So, I did some more testing focussing on COM+ and the MS DTC
(Distributed Transaction Controller). The DTC is the chappy that
handles 2-phase commits across more than one database. In my case
there are at least 2 databases being updated. Our DB, and one or more
of Biztalk's. All DBs are running under the same instance of SQL
Server.
It definitely seems to be be DTC related problem in that once I get
the message, "DTC is tearing down the session", I can successfully
submit the doc using IInterchange.Submit with the same document that
previously failed with the 0x0139 error using a VB test-bed program
that only calls IInterchange.Submit. If I don't get the message, then
the test-bed fails with the 0x0139 error. This seems odd as test-bed
'transaction', while submitting the same document as the AIC was
trying to do, did not exist. (I.e. if there was a 'transaction' it was
completely initiated and controlled by IInterchange.Submit running
under COM+.)
Rather than waiting the default 10 minutes for DTC to "tear down the
session", if I go into Component Services and manually stop DTC, I can
immediately submit the document again. In either situation, the
document flys through without error.
Thus the problem would appear to be between how IInterchange.Submit
and DTC are communicating. I tried numerous scenerios with the AIC
using different COM+ transactional properties (requires trans, uses
trans, not supported, etc.) and all either never worked or worked only
intermitantly.
The situation Im looking for is that the IInterchange.Submit carries
the same 'state' (DB transaction) as the AIC. I.e. If the AIC fails at
any point, the IInterchange.Submit fails also and I can rely on
BizTalks retry mechanisms to try again.
Has anyone come across this before? Is there a fix? Surely
re-submitting a document for a second pass through BT isn't that
unusual?
Any help gratefully accepted as the work around (writing the document
to 'our DB' and then having a polling job to submit it) is both slow
and ugly.
|
|
|
|
|