Re: Running two instances of BizTalk generated code?

Hi Jeff,
There is a new book the "Pro BizTalk 2006", chapter 2 is about your things
(Side-by-side deployment). Maybe it would help.
You can install several BTS-Apps simultaneously but with some differences!
Do not throw the idea with several VM. In this case you need those VM have
DIFFERENT server names! This issue was many times described in inet.
One of the faster method is to make the VM without BTS, clone it, change
names, install BTS on each.

--

Regards,

Leonid Ganeline
BizTalk Developer,
Microsoft Certified Technology Specialist: BizTalk Server 2006
http://geekswithblogs.net/leonidganeline/
"Jeff Tressler" <JeffTressler@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:75DF4DD2-F44B-4178-9632-E2333450AB34@xxxxxxxxxxxxxxxx
Ok, not a really easy way of doing this but it is possible? I have been
told
absolutly this must be done without using virtual machines. It does not
matter how difficult it is, does not matter how complex the changes to
compoinent names or changes to orchestrations, I MUST find a way to
support
four environments on a single machine without using virtual machines. Any
idea?

Perhaps even more details.

We have a WebSphere Application Server running our primary application.
This WAS is configured to talk to a queue manager running on UNIX. This
queue
manager (IBM WebSphere MQ) can handle request/reply where the application
send request, saves MsgId and reads the proper response via the Correl Id.
If
this was all there was too it, I would be fine. But there are two other
interfaces where the application on the WAS cannot know if the response is
thiers. One process sends request but since there is not a user waiting at
a
web screen, the sending process ignores any responses, it leave another
application to sit there read ANY message that shows and processes it.
Since
our INT and QT WAS applications are currently being fed by a single
BizTalk
instance, any response of this type can be read by either. So if the
Integration people initiate a request, the QA environment may read the
response and process it even though they did not generate it.

If I had two BizTalk instances, running on two computers or in two virtual
machines, each could load the exact same code, talk to two different queue
managers. So INT and QT are isolated and when one sends a request, it will
go
o different BizTalk servers which are configured to talk to their queue
manager only. We would have a INT WAS, INT queue manager, and INT BizTalk
server. We would have a QT WAS, QT queue manager, and a QT BizTalk server.

But we have only one BizTalk server and can only run one BizTalk server,
no
tricks like virtual machines due to license issues. So if I could find a
say
to deploy our code multiple times on the same server, I could configure
each
instance to talk to a different queue manager as if they were on different
servers. It would be like loading Application A and Application B which is
done all the time but in this case, A and B have the same orchestrations,
same schema, same assemblies, etc.

Initally I tried the following.

Use BizTalkApplicationServer as the default Host Instance. I did a regular
deplay and it worked. I then created a second Host Instance, set this up
as
the default and tried a deploy with no changes. Unfortunatly, the send
ports
are not associated with a particular Host Instance, receive locations are
tied to a Host Instance but send ports are not. Also the various assembles
are not associated with a specific Host Instance. So when the second
deploy
is attempted, I get error messages about assemblies already deployed and
the
deploy fails.

Now I am trying to alter the assembly names and just the assembly names. I
hope this will allow the assembles, containing the same stuff but with
different names to coexist in the mysterious common area that is not part
of
the Host Instance. I have run into a few errors that I am trying to
resolve.
Unfortunatly I believe this will also prove to be a dead end.

I suspect I will have to treat every single step of the configuration path
as a different application just as if I were to load a BizTalk application
from Company A and a different BizTalk application from Company B. I am
afraid this will require renaming most if not all components, make changes
to
Orchestrations that reference these componetns, and who knows what other
changes. So after the Integration testers complete thier tests, I would
have
to rename everything, make extensive changes to various orchestrations and
custom pipelines and then recompile what is basically an entirely
different
applicaiton. Kinda defeats the purpose of Integration testing if the QT
testers get different code. Not to mention Customer Testing and Production
each getting a "different" application.

Figure this is as confusing as my other attempts, hope it kept you
entertained at least.

--
There are 10 kinds of people, those who understand binary and those that
don''''''''t
There''''''''s no place like 127.0.0.1
================================
3.14159 + Ice Cream = Pi ala mode


"Leonid Ganeline" wrote:

Hi Jeff,

What do U mean as "Integration and a QA configuration"?

Anyway try to use two VMs with two BTS for testing.
Why testing a different from production configuration?

--

Regards,

Leonid Ganeline
BizTalk Developer,
Microsoft Certified Technology Specialist: BizTalk Server 2006
http://geekswithblogs.net/leonidganeline/

"Jeff Tressler" <JeffTressler@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:002A59AD-A6DE-4C8E-ABAD-5C6257A6D9B6@xxxxxxxxxxxxxxxx
Not quite. We have programmed an application that actually contains 11
orchestrations. It processes quite a number of messages. Since I have
only
one computer, I have the BizTalk orchestrations deployed to a host
instance
(BizTalkApplicationServer) and both INT and QT send their requests to a
queue
manager MQ queue. Most of these requests us the MsgId/CorrelId
processing
so
INT and QT know which response is theirs.

Unfortunatly, some of the messages so not support the MsgId/CorrelId
method
of identification so the INT and QT applications are configured to read
every
message of those types that BizTalk sends. If INT generates a test that
produces 500 messages, both INT and QT processes grab the results so
half
go
to INT and half go to QT. It is the exact same message, the same
schema,
generated by the same Orchestration. There is nothing in the message to
identify it should go to INT or QT.

In production, there will be only one version of the application code
running, but for now we have INT and QT applications that need support
by
a
single BizTalk server. If I could find some way to create two copies of
the
BizTalk code, each could be configured to talk to different queue
managers
and thus would only generate the messages its queue manager and thus
INT
would grab everything but it would be isolated because it has its own
BizTalk
instance of the code.

And since we are talking configuration mangment, I need to make the
fewest
changes possible to generate these two instances since the code tested
by
INT
gets promoted to QT. If I have to rename huge number of components to
get
them to play well together, that means once INT completes its testing,
I
have
to rename, alter Orchesrations, etc before building it for QT and that
kinda
defeats the purpose of the INT environment since QT will be effectivly
testing different code.

Hope that makes more sense.
--
There are 10 kinds of people, those who understand binary and those
that
don''''''''t
There''''''''s no place like 127.0.0.1
================================
3.14159 + Ice Cream = Pi ala mode


"Jan Eliasen" wrote:

On Mon, 18 Dec 2006 06:12:00 -0800, Jeff Tressler
<JeffTressler@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

We have one computer and one BizTalk licence. Our BizTalk application
reads
requests from a MQSeries queue, processes the response and writes to
another
MQSeries queue. A process reads everything that arrives on that
queue. I
need
to find some way to have this BizTalk process running on the same
computer to
support an Integration and a QA configuration. There is nothing about
the
messages that can identify which request came from which (INT or QA)
and
each
will attempt to read all messages that arrive on the queue.
I am failing to understand what you are trying to accomplish.

Have I understood it correctly, that you have an orchestration that
can accept and process a specific messagetype, and you need another
orchestration that does the same processing, but on another
messagetype?

In that case, take all the functoinality that must be shared between
those two orchestrations, and put it into another orchestration, that
can be called from other orchestrations. Then, just have two
orchestrations, processing different messagetypes, and bind them to
the same physical receive port. Let them call the common orchestration
that has the shared code. This will work for as many messagetypes you
need it to.

--
eliasen, representing himself and not the company he works for.

Private blog: http://blog.eliasen.dk

Private email: jan@xxxxxxxxxx






.

Relevant Pages

  • Re: Running two instances of BizTalk generated code?
    ... compoinent names or changes to orchestrations, I MUST find a way to support ... This WAS is configured to talk to a queue manager running on UNIX. ... our INT and QT WAS applications are currently being fed by a single BizTalk ...
    (microsoft.public.biztalk.general)
  • Re: Running two instances of BizTalk generated code?
    ... We only have on license to support both INT and QT. ... At this point we have ONE BizTalk license and managment is interpreting this ... I have the BizTalk orchestrations deployed to a host ... manager MQ queue. ...
    (microsoft.public.biztalk.general)
  • Re: Running two instances of BizTalk generated code?
    ... I have the BizTalk orchestrations deployed to a host instance ... manager MQ queue. ... INT and QT know which response is theirs. ... message of those types that BizTalk sends. ...
    (microsoft.public.biztalk.general)
  • Re: Running two instances of BizTalk generated code?
    ... What do U mean as "Integration and a QA configuration"? ... I have the BizTalk orchestrations deployed to a host ... manager MQ queue. ... INT and QT know which response is theirs. ...
    (microsoft.public.biztalk.general)
  • Re: If I have the possibility to go back in time, 3 months ago, what will I do?
    ... I can say that Biztalk is being used for ... SQL Server to store a list of images, you can use Biztalk for simple ... >> orchestrations in a twisted way, and it just leaks memory if you call ... >> complaining until you change your design to use the tool better. ...
    (microsoft.public.biztalk.general)