Hi all
I have a question to do with running a BTS 2005 orchestration.

We use a set of .Net assemblies to provide us with logging and monitoring
capabilities.  The logging works by calling a method which uses the current
thread WindowsPrincipal to log information about the user.  This all works
fine when we are running our own assemblies under iis (we have a httpmodule
that assigns these details to the thread that iis creates).

Is it possible to do something similar when running bts orchs i.e. assign
the generic princiapl to the current thread thereby alowing our logging
assembly
to see it and log details?

I have a trusted iosolated host receiving SOAP messages and the windows user
information is passed into the message box in the message box.

Cheers for any help

Anthony Pounder
Nottingham - UK

[ Post a follow-up to this message ]

Anthony,

> We use a set of .Net assemblies to provide us with logging and monitoring
> capabilities.  The logging works by calling a method which uses the
> current
> thread WindowsPrincipal to log information about the user.  This all works
> fine when we are running our own assemblies under iis (we have a
> httpmodule
> that assigns these details to the thread that iis creates).
>
> Is it possible to do something similar when running bts orchs i.e. assign
> the generic princiapl to the current thread thereby alowing our logging
> assembly
> to see it and log details?
>
> I have a trusted iosolated host receiving SOAP messages and the windows
> user
> information is passed into the message box in the message box.

You might be able to do it, but it would likely have to be done very
carefully. The main problem here is that orchestrations don't run beginning
to end in the same thread, so you certainly can't create the principal and
attach it to the thread at the start of the orchestration and just hope it
is always there (except in very particular scenarios like on a fully atomic
transaction or something).

The second problem is that we really have no information on the
implementation details of the orchestration engine; thus, we can't reliably
tell whether the engine itself might use the thread's principal for any
particular task, and whether it might get confused if you change it.

My only suggestion here would be to use a GenericPrincipal you instantiate
from the SOAP.UserName property, and just try to minimize the time it is
attached to the thread. For example, when calling the external components
temporarily attach your custom principal to the thread at the start of the
Expression shape, call your component, and then immediately restore the
original principal before exiting the expression shape. And, test this *a
lot* to ensure no problems occur.


--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/

[ Post a follow-up to this message ]

"Tomas Restrepo (MVP)" <tomasr@mvps.org> wrote in message
news:eF1KQxvkFHA.3380@TK2MSFTNGP12.phx.gbl...
> Anthony,
>
> My only suggestion here would be to use a GenericPrincipal you instantiate
> from the SOAP.UserName property, and just try to minimize the time it is
> attached to the thread. For example, when calling the external components
> temporarily attach your custom principal to the thread at the start of the
> Expression shape, call your component, and then immediately restore the
> original principal before exiting the expression shape. And, test this *a
> lot* to ensure no problems occur.
>
Thomas, thanks for your reply.  It states the concern that I already had:
it's probably
not a good idea!  I have an option (which I'm already using) to call a web
service and
pass the UserName property through in a SOAP header.  The WS can then create
a generic principal and do the logging but it doesn't help me with the
loggin while in the
orch.  Ill try your idea of creating a generic principal and assigning it
briefly to the thread
whlst calling the logging component.  I'll test it * a lot*.

Thanks for taking the time to reply.

Anthony Pounder
Nottingham - UK

[ Post a follow-up to this message ]