Hi,

I am interested to find out how Biztalk stores received XML messages
(and any transformed/constructed ones). I have built a small workflow
proof-of-concept that utilises the BizTalk HTTP Receive adapter.

The workflow is a Leave Request form that submits to BizTalk,
instantiates an assembly that looks up their manager and a variety of
AD details and sends a confirmation to the user and a to-be-actioned
email to their manager (there is an action process that follows that
is kicked off by the manager).

I would like to be able to extract the original XML message after an
orchestration has completed (for example in a timeout/exception
scenario, ie No manager deails in AD)

The purpose of this to be able to automatically resubmit a request for
a user that had previously failed, after the exception condition has
been rectified.

I appreciate I could handle this internally to the orchestration,
however I am interested in immersing myself in the how the system
works to be able to build better real-world applications in the
future.

Regards,

Lincoln

[ Post a follow-up to this message ]

After ferreting around the web (doing unrelated biztalk searches!), I found 
a few WMI solutions - the best being:
http://blogs.msdn.com/darrenj/archi.../30/104135.aspx

Is WMI the preferred method to access this type of information?

Regards,

Lincoln

"Lincoln Broomhall" wrote:

> Hi,
>
> I am interested to find out how Biztalk stores received XML messages
> (and any transformed/constructed ones). I have built a small workflow
> proof-of-concept that utilises the BizTalk HTTP Receive adapter.
>
> The workflow is a Leave Request form that submits to BizTalk,
> instantiates an assembly that looks up their manager and a variety of
> AD details and sends a confirmation to the user and a to-be-actioned
> email to their manager (there is an action process that follows that
> is kicked off by the manager).
>
> I would like to be able to extract the original XML message after an
> orchestration has completed (for example in a timeout/exception
> scenario, ie No manager deails in AD)
>
> The purpose of this to be able to automatically resubmit a request for
> a user that had previously failed, after the exception condition has
> been rectified.
>
> I appreciate I could handle this internally to the orchestration,
> however I am interested in immersing myself in the how the system
> works to be able to build better real-world applications in the
> future.
>
> Regards,
>
> Lincoln
>

[ Post a follow-up to this message ]

Lincoln:

As you know, the content (XML data in your case) is stored in stream as
body part of the biztalk message alone with Context property. The physical
data storage in SQL is in binary blob and some time fragmented in case of
large message. Having said that, I don't think you would want to do that if
that is your original intention.

The question I have for you is typically an Orchestration depicts a
complete work-flow or sub-workflow that can be activated by another parent
orchestration. So when you say "extract (process) the original XML message
after an orchestration has completed", this means that that work-flow has
NOT been completed. It sounds like you have to design the orchestration so
that any error conditions (timeout/exceptions) are handled in the same
orchestration schedule.

- Allen Zhang (MSFT)

This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
>
> Hi,
>
> I am interested to find out how Biztalk stores received XML messages
> (and any transformed/constructed ones). I have built a small workflow
> proof-of-concept that utilises the BizTalk HTTP Receive adapter.
>
> The workflow is a Leave Request form that submits to BizTalk,
> instantiates an assembly that looks up their manager and a variety of
> AD details and sends a confirmation to the user and a to-be-actioned
> email to their manager (there is an action process that follows that
> is kicked off by the manager).
>
> I would like to be able to extract the original XML message after an
> orchestration has completed (for example in a timeout/exception
> scenario, ie No manager deails in AD)
>
> The purpose of this to be able to automatically resubmit a request for
> a user that had previously failed, after the exception condition has
> been rectified.
>
> I appreciate I could handle this internally to the orchestration,
> however I am interested in immersing myself in the how the system
> works to be able to build better real-world applications in the
> future.
>
> Regards,
>
> Lincoln
>

[ Post a follow-up to this message ]

Hi Allen,

Thanks for your reply. I still feel there is a case for resubmission as a ca
tch-all for fatal errors, however I completely concur with handling as much 
as possible in workflows.

Regards,

Lincoln

"Allen Zhang (MSFT)" wrote:

> Lincoln:
>
> As you know, the content (XML data in your case) is stored in stream as
> body part of the biztalk message alone with Context property. The physical
> data storage in SQL is in binary blob and some time fragmented in case of
> large message. Having said that, I don't think you would want to do that i
f
> that is your original intention.
>
> The question I have for you is typically an Orchestration depicts a
> complete work-flow or sub-workflow that can be activated by another parent
> orchestration. So when you say "extract (process) the original XML message
> after an orchestration has completed", this means that that work-flow has
> NOT been completed. It sounds like you have to design the orchestration so
> that any error conditions (timeout/exceptions) are handled in the same
> orchestration schedule.
>
> - Allen Zhang (MSFT)
>
> This posting is provided "AS IS" with no warranties, and confers no rights
.
> -------------------- 
>
>

[ Post a follow-up to this message ]

Hi Allen,

Thanks for your reply. I still feel there is a case for resubmission as a ca
tch-all for fatal errors, however I completely concur with handling as much 
as possible in workflows.

Regards,

Lincoln

"Allen Zhang (MSFT)" wrote:

> Lincoln:
>
> As you know, the content (XML data in your case) is stored in stream as
> body part of the biztalk message alone with Context property. The physical
> data storage in SQL is in binary blob and some time fragmented in case of
> large message. Having said that, I don't think you would want to do that i
f
> that is your original intention.
>
> The question I have for you is typically an Orchestration depicts a
> complete work-flow or sub-workflow that can be activated by another parent
> orchestration. So when you say "extract (process) the original XML message
> after an orchestration has completed", this means that that work-flow has
> NOT been completed. It sounds like you have to design the orchestration so
> that any error conditions (timeout/exceptions) are handled in the same
> orchestration schedule.
>
> - Allen Zhang (MSFT)
>
> This posting is provided "AS IS" with no warranties, and confers no rights
.
> -------------------- 
>
>

[ Post a follow-up to this message ]