10-27-04 12:46 PM
Lars,
Yes, using a database Error Return functoid in your map is definitely an
option,
but yes I think this is a poor design. I would be much more comfortable
using a receive port.
Also don't rule out using your own custom .Net component that uses ADO.NET
to retrieve the info from the database. If the retrieved data needs to be in
an XML format, then you can use the XML EXPLICIT option(giving you complete
control on how the retrieved XML will look) in your select
statement. This XML can be used to populate a message inside your
Ochestration. In the Sql Adapter you are stuck with XML AUTO. If your custom
ADO.NET code fails due to a Sql error, you can trap the error in the
Orchestration and retry.
Matt
"Lars W. Andersen" wrote:
> Hi,
>
> I could use some advice on an issue I have. I need to introduce some erro
r
> handling to an interface.
>
> The scenario is:
> I receive a message that I want to update or insert into an SQL table. For
> this I use the updategram, and that works fine.
>
> In my map I do a DB lookup to decide whether I should create an insert or
an
> update statement. I then use the value mapper to decide if I should create
> the <before> part of the updategram, along with the result of my DB lookup
.
>
> My problem is:
> This worked really well on my testbox, but as soon as I let it loose the
> harsh realities showed me that if the DB lookup failed, (DB unavailable or
> other proiblem) I end up inserting a new (duplicate) record into the table
,
> as the updategram/value mapper didnt create the <before> tag and I wasnt
> able to state the "key" in the <before> elements.
>
> So my question is now how I should design this. Should I move the DB look
up
> out of the map and into a separate receive port in an orchestration? This
> would enable me to use the read retry on the SQL receive port, and if that
> fails the exception handling in an orchestration. That is the only thing
I
> can think of right now. Anybody have any other suggestions?
>
> I might also write the DB lookup error into a new element. Promote it as a
> property and when it exists move it through an orchestration that does som
e
> error handling? But what should that error do.
>
> regards
> Lars
>
>
>
>
[ Post a follow-up to this message ]
| 
Been doing BizTalk too long I guess ... haha.
regards
Lars
"Matt Meleski" <MattMeleski@discussions.microsoft.com> wrote in message
news:9B74A88C-1485-43C0-BAAF-E4FC33A86702@microsoft.com...
> Lars,
>
> Yes, using a database Error Return functoid in your map is definitely an
> option,
> but yes I think this is a poor design. I would be much more comfortable
> using a receive port.
> Also don't rule out using your own custom .Net component that uses ADO.NET
> to retrieve the info from the database. If the retrieved data needs to be
in
> an XML format, then you can use the XML EXPLICIT option(giving you
complete
> control on how the retrieved XML will look) in your select
> statement. This XML can be used to populate a message inside your
> Ochestration. In the Sql Adapter you are stuck with XML AUTO. If your
custom[vbcol=seagreen]
> ADO.NET code fails due to a Sql error, you can trap the error in the
> Orchestration and retry.
>
> Matt
>
> "Lars W. Andersen" wrote:
>
error[vbcol=seagreen]
For[vbcol=seagreen]
or an[vbcol=seagreen]
create[vbcol=seagreen]
lookup.[vbcol=seagreen]
or[vbcol=seagreen]
table,[vbcol=seagreen]
lookup[vbcol=seagreen]
This[vbcol=seagreen]
that[vbcol=seagreen]
thing I[vbcol=seagreen]
a[vbcol=seagreen]
some[vbcol=seagreen]
