Is this possible?

[ Post a follow-up to this message ]

Re: Start vbscript from orchestration

"Joakim Johansson" <pezmannen@walla.com> wrote in message
news:%23XES9a3OFHA.3072@TK2MSFTNGP09.phx.gbl...
> Is this possible?
>


Yes, actually someone wrote an adapter for it:

http://mcgeeky.blogspot.com/2005/03...pt-adapter.html

[ Post a follow-up to this message ]

I found this yesterday. Isn't there an easier way to do this?

BA wrote:
> Re: Start vbscript from orchestration
>
> "Joakim Johansson" <pezmannen@walla.com> wrote in message
> news:%23XES9a3OFHA.3072@TK2MSFTNGP09.phx.gbl...
> 
>
>
>
> Yes, actually someone wrote an adapter for it:
>
> http://mcgeeky.blogspot.com/2005/03...pt-adapter.html
>
>
>

[ Post a follow-up to this message ]

Hello Joakim,


Inside an Orchestration there is no problem calling a .NET assembly.

Similarly from a .NET component there is no problem calling a vbscript.

You can use  System.Diagnostic.Process.Start to start a vbscript from .NET
assembly.
HTH
--
Cheers
Saravana Kumar
MCP - Biztalk Server 2004 (http://saravanakumarmv.blogspot.com)


"Joakim Johansson" <pezmannen@walla.com> wrote in message
news:#XES9a3OFHA.3072@TK2MSFTNGP09.phx.gbl...
> Is this possible?
>
>

[ Post a follow-up to this message ]

Thanks!

So, why should I use the adapter instead of System.Diagnosti......?


"Saravana Kumar" <saravana@hotmail.co.uk> wrote in message
news:eGIr5PoPFHA.3076@TK2MSFTNGP12.phx.gbl...
> Hello Joakim,
>
>
> Inside an Orchestration there is no problem calling a .NET assembly.
>
> Similarly from a .NET component there is no problem calling a vbscript.
>
> You can use  System.Diagnostic.Process.Start to start a vbscript from .NET
> assembly.
> HTH
> --
> Cheers
> Saravana Kumar
> MCP - Biztalk Server 2004 (http://saravanakumarmv.blogspot.com)
>
>
> "Joakim Johansson" <pezmannen@walla.com> wrote in message
> news:#XES9a3OFHA.3072@TK2MSFTNGP09.phx.gbl... 
>
>

[ Post a follow-up to this message ]

Its difficult for me to resist responding to this thread!

> So, why should I use the adapter instead of System.Diagnosti......?

First off, I think you should use whichever approach best suits your needs.
Why not give the script adapter a go and see how you get on.

Some reasons why the script adapter might be a better choice than launching
a script as an external process from an orchestration?
1. You can write a one way or two way send adapter - very rapidly
2. Logically, its a much clearer separation of responsibility
3. The script adapter wraps the message and context properties with an
object that is made available to your script
4. The configuration (ie. which script to run and what custom parameters are
passed to it) is managed using the BizTalk explorer in the same way as any
other send port
5. BizTalk can be configured to run the script adapter in a separate process
so that the script does not interfere with the orchestration should it fail
spectacularly
6. Any failed messages can be resubmitted to the script adapter using the
HAT in the normal way

--
McGeeky
http://mcgeeky.blogspot.com


"Joakim Johansson" <pezmannen@walla.com> wrote in message
news:%23PS2utBRFHA.612@TK2MSFTNGP14.phx.gbl...
> Thanks!
>
> So, why should I use the adapter instead of System.Diagnosti......?
>
>
> "Saravana Kumar" <saravana@hotmail.co.uk> wrote in message
> news:eGIr5PoPFHA.3076@TK2MSFTNGP12.phx.gbl... 
.NET[vbcol=seagreen] 
>
>

[ Post a follow-up to this message ]

Thanks for your reply and I can see your point. I had problems understanding
how to use the adapter, that's why I was looking for other solutions. Also,
if you are using a script that you don't want to modify (OnMessage) it's not
possible to use the adapter, right?

"McGeeky" <anon@anon.com> wrote in message
news:uxHmDSCRFHA.1392@TK2MSFTNGP10.phx.gbl...
> Its difficult for me to resist responding to this thread!
> 
>
> First off, I think you should use whichever approach best suits your
> needs.
> Why not give the script adapter a go and see how you get on.
>
> Some reasons why the script adapter might be a better choice than
> launching
> a script as an external process from an orchestration?
> 1. You can write a one way or two way send adapter - very rapidly
> 2. Logically, its a much clearer separation of responsibility
> 3. The script adapter wraps the message and context properties with an
> object that is made available to your script
> 4. The configuration (ie. which script to run and what custom parameters
> are
> passed to it) is managed using the BizTalk explorer in the same way as any
> other send port
> 5. BizTalk can be configured to run the script adapter in a separate
> process
> so that the script does not interfere with the orchestration should it
> fail
> spectacularly
> 6. Any failed messages can be resubmitted to the script adapter using the
> HAT in the normal way
>
> --
> McGeeky
> http://mcgeeky.blogspot.com
>
>
> "Joakim Johansson" <pezmannen@walla.com> wrote in message
> news:%23PS2utBRFHA.612@TK2MSFTNGP14.phx.gbl... 
> .NET 
>
>

[ Post a follow-up to this message ]

Thats some good extra info about your adapter, you should post it on the got
dot net workspace you have.

(the most important one is that it runs outside BTS, in my opinion)

Cheers


"McGeeky" <anon@anon.com> wrote in message
news:uxHmDSCRFHA.1392@TK2MSFTNGP10.phx.gbl...
> Its difficult for me to resist responding to this thread!
> 
>
> First off, I think you should use whichever approach best suits your
> needs.
> Why not give the script adapter a go and see how you get on.
>
> Some reasons why the script adapter might be a better choice than
> launching
> a script as an external process from an orchestration?
> 1. You can write a one way or two way send adapter - very rapidly
> 2. Logically, its a much clearer separation of responsibility
> 3. The script adapter wraps the message and context properties with an
> object that is made available to your script
> 4. The configuration (ie. which script to run and what custom parameters
> are
> passed to it) is managed using the BizTalk explorer in the same way as any
> other send port
> 5. BizTalk can be configured to run the script adapter in a separate
> process
> so that the script does not interfere with the orchestration should it
> fail
> spectacularly
> 6. Any failed messages can be resubmitted to the script adapter using the
> HAT in the normal way
>
> --
> McGeeky
> http://mcgeeky.blogspot.com
>
>
> "Joakim Johansson" <pezmannen@walla.com> wrote in message
> news:%23PS2utBRFHA.612@TK2MSFTNGP14.phx.gbl... 
> .NET 
>
>

[ Post a follow-up to this message ]

Hi Joakim,

Its unfortunate that the script adapter documentation is not more
accessible. I will look at improving it.

In answer to your question: you are right - your script must implement the
OnMessage procedure. You have two options; to add an OnMessage procedure to
your existing script or to create a new script which implements OnMessage
which then calls your existing script. The script adapter does not currently
support the latter case (nor does vbscript) where one script can include
another (though I am considering such an enhancement) so you must use the
following technique:

http://www.source-code.biz/snippets/vbscript/5.htm

This is a common technique to use. It loads the "included script" in to a
string which is then "evaluated". This has the effect of importing all the
included script's procedures which you can then call. If the included script
has code in the global space then it will be executed automically on
evaluation.

If you use the script adapter and would like to see an includes feature then
I will consider you as a vote +1 for it!

Note: Windows scripting does support includes through wsf files

--
McGeeky
http://mcgeeky.blogspot.com


"Joakim Johansson" <pezmannen@walla.com> wrote in message
news:eavNPlCRFHA.2384@tk2msftngp13.phx.gbl...
> Thanks for your reply and I can see your point. I had problems
understanding
> how to use the adapter, that's why I was looking for other solutions.
Also,
> if you are using a script that you don't want to modify (OnMessage) it's
not
> possible to use the adapter, right?
>
> "McGeeky" <anon@anon.com> wrote in message
> news:uxHmDSCRFHA.1392@TK2MSFTNGP10.phx.gbl... 
any[vbcol=seagreen] 
the[vbcol=seagreen] 
vbscript.[vbcol=seagreen] 
>
>

[ Post a follow-up to this message ]

> Thats some good extra info about your adapter, you should post it on the
got
> dot net workspace you have.

Good point. I'll look in to it.

> (the most important one is that it runs outside BTS, in my opinion)

Well, perhaps my post was slightly misleading. The script adapter does not
run outside the BizTalk process - it must run within a BizTalk process. But
you can configure the adapter, as with any other send adapter, to run in a
separate BizTalk process to the one that your orchestration uses. Use the
BizTalk Administration Console to do that. For example - you could have a
BizTalk host called "BizTalk Scripting Host". This will give you a good
level of robustness should a script fail badly.


--
McGeeky
http://mcgeeky.blogspot.com


"BA" <biztalk.architect@gmail.com> wrote in message
news:1113839119. b45eee94e9edd14ac4d19ddb9b1cb518@teranew
s...
> Thats some good extra info about your adapter, you should post it on the
got
> dot net workspace you have.
>
> (the most important one is that it runs outside BTS, in my opinion)
>
> Cheers
>
>
> "McGeeky" <anon@anon.com> wrote in message
> news:uxHmDSCRFHA.1392@TK2MSFTNGP10.phx.gbl... 
any[vbcol=seagreen] 
the[vbcol=seagreen] 
vbscript.[vbcol=seagreen] 
>
>

[ Post a follow-up to this message ]