|
Home > Archive > BizTalk Server > March 2005 > Biztalk calls map twice
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 |
Biztalk calls map twice
|
|
| brandonnewsgroup@hotmail.com 2005-03-08, 5:49 pm |
| BTS 2002 SP1
We have biztalk setup to accept hipaa x12 incoming messages and return
hipaa x12 outgoing messages.
In normal cases, Biztalk will convert the x12 messages to xml, call the
map, convert the output xml back to x12 and return the x12 message.
However, if there is a processing problem in the map, biztalk will call
it twice.
It can be reproduced when the map is hardcoded to always return
"<test>abc</test>"
Biztalk is following this logic.
IncomingXML=Convert(IncomingX12)
attempt=0
repeat
attempt=attempt+1
Log(IncomingXML)
OutgoingXML=RunMap(incomingXML)
OutgoingX12=Convert(OutgoingXML)
Valid = isValid(OutgoingX12)
Until valid or attempt>=2
If valid then
Log(OutgoingXML)
Else
EventLog("The XML document has failed validation for the following
reason:..")
End if
What I don't understand is why there would be ANY circumstance in
which repeating the RunMap automatically would be desirable.
If the map is stateless, then it will return the same error for both
calls (making the second call harmless but useless).
If the map is stateful, then calling twice causes a transaction to get
submitted twice (this is what is happening for us).
Oddly, if the second call succeeds, biztalk shows no record that the
first call ever failed.
Can anyone shine some light on why biztalk does this?
Is there any way to get biztalk to log the OUTGOING xml even when it
can not be converted (this is when the logs are most needed)?
Is there any way to force biztalk to go with the results of the first
call to the map and not try again?
I don't think this is related to the channel's retry options which are
left at 3 retrys in 5 minute intervals.
| |
| Joerg Fischer 2005-03-10, 7:47 am |
| Hi,
If you access anything outside the inbound pipeline, like DBs, here is a
hint: After installing BizTalk SP1, there is a new interface provided
(PipelineContextEx) which allows you to access the DTC transaction of the
pipeline.
That way, you can ensure that if anything fails, things are rolled back.
Sincerely
Joerg Fischer
<brandonnewsgroup@hotmail.com> wrote in message
news:1110305444.449530.305310@z14g2000cwz.googlegroups.com...
> BTS 2002 SP1
>
> We have biztalk setup to accept hipaa x12 incoming messages and return
> hipaa x12 outgoing messages.
>
> In normal cases, Biztalk will convert the x12 messages to xml, call the
> map, convert the output xml back to x12 and return the x12 message.
>
> However, if there is a processing problem in the map, biztalk will call
> it twice.
>
> It can be reproduced when the map is hardcoded to always return
> "<test>abc</test>"
>
> Biztalk is following this logic.
>
> IncomingXML=Convert(IncomingX12)
> attempt=0
> repeat
> attempt=attempt+1
> Log(IncomingXML)
> OutgoingXML=RunMap(incomingXML)
> OutgoingX12=Convert(OutgoingXML)
> Valid = isValid(OutgoingX12)
> Until valid or attempt>=2
>
> If valid then
> Log(OutgoingXML)
> Else
> EventLog("The XML document has failed validation for the following
> reason:..")
> End if
>
>
> What I don't understand is why there would be ANY circumstance in
> which repeating the RunMap automatically would be desirable.
>
> If the map is stateless, then it will return the same error for both
> calls (making the second call harmless but useless).
>
> If the map is stateful, then calling twice causes a transaction to get
> submitted twice (this is what is happening for us).
>
> Oddly, if the second call succeeds, biztalk shows no record that the
> first call ever failed.
>
> Can anyone shine some light on why biztalk does this?
>
> Is there any way to get biztalk to log the OUTGOING xml even when it
> can not be converted (this is when the logs are most needed)?
>
> Is there any way to force biztalk to go with the results of the first
> call to the map and not try again?
>
> I don't think this is related to the channel's retry options which are
> left at 3 retrys in 5 minute intervals.
>
|
|
|
|
|