From:Kengo Kuwamura
Sent:Wednesday, October 22, 2003 5:08 PM
To:Sharon McGuinness
Cc:Jon Bossman; Michael Pastore
Subject:RE: MTS vs. Inproc
Hmmm... Many questions...
Let's see if I can give you some good explanations...
The first item is the "InProc" and "MTS/COM+". The term "InProc" is coming from "In-Process", and something used among COM/DCOM community. When starting an application like WinStudio, Windows assign a process within memory; that's the memory boundary WinStudio lives in, and other applications would have their own process. Windows is to maintain these processes separately so that each application would not step into other applications memory; if something like that happens, then we can kill those applications, right...? Now, how COM works is when client application (in this case WinStudio) creates an instance of COM object (COM server object), under the "InProc" environment the instance of requested COM object is to be created within the same process of caller/client application (WinStudio). On the other hand, under the "MTS/COM+" environment, those COM objects are managed by COM+ (Windows system service); it has its own process boundary, and those COM object instances live under the management of COM+. When requesting an instance of COM objects, running under COM+ application, WinStudio is basically creating a stub object within its process boundary. That stub looks and acts like the actual COM objects running under COM+ application, and WinStudio would be talking to the stub instead of actual object instance running at the COM+; little more technical, but these stub objects are to work with something called proxy at the target side to communicate back and forth (something called marshalling - sending data stream back and forth among different memory process boundaries). Making sense..., kinda...??? Anyway, those are COM/DCOM background that you may need to further read through some books (it can become pretty complicated; COM/DCOM technology itself is pretty complicated, and our toolset is to hide those complicated stuff from users and do all the dirty work).
Now, little more COM/DCOM background... This technology relies on registry depository to locate the actual DLL files. As you are ware of, you use "regsvr32" to register/unregister those COM/DCOM objects into your systems. Top of that COM+ has its own database to keep track of where the actual DLL files are located on your systems; you can see COM+ assigning unique GUID's for each COM components if you right-click on any components registered under COM+ (Component Service MMC Plug-In) to select its "Properties" option menu, and you can see its GUID assigned by COM+ (that's actually nothing to do with what's registered on registry database). So, when you build your IDO COM objects, COM+ would not recognize your newly-built objects until you reregister them under COM+. That's why we are saying that you want to stay with "InProc" when developing/modifying IDO DLL files; it's possible to your IDO development under COM+, but everytime you rebuild your COM objects, you will need to reregister them under COM+ (actually delete them from COM+ applications and readd them). Little painful, isn't it...? That's why we are saying you want to work under "InProc".
OK, next question...
Then, you probably need to get rid of those COM+ applications running on your machine; then, re-register those IDO and other COM objects on your machine using "regsvr32" utility beside using the right version of SymixDB.
What does that mean...? Well, if you are running under COM+/MTS environment (BTW; MTS stands for "Microsoft Transaction Service", and it was the start of those transaction services provided by Microsoft at the time of NT4, and MS has been enhancing the service and starting W2K integrated into OS as COM+ - so, COM+ is the superset of MTS), you do need to do some manual setup so that your machine can be switched from "COM+/MTS" to "InProc". Here is something I wrote long time ago for those BP's who used to ask us the same question; hoping that following those instructions will get you the right environment for you.
Little more to go...
"SymixDB.dll"; that's the core database connection DLL used by IDO's, and we do have two flavors of it - "InProc" and "COM+/MTS" versions. The way initiating, commiting, and rolling back transactions under "InProc" and "COM+/MTS" can be little different, we do have this "SymixDB.dll" built for each specific environment. You do need to have the right version for the systems to work properly.
"IDORegSvr" utility; it's a nice utility, and you could use it to register those IDO COM objects;
"<SL7 Install Dir>\IDO\IDORegSvr.exe" Adapters.dll Admin.dll
You may simply use "regsvr32" to register/unregister those COM objects as well. Now, that utility's main purpose is to add an extra registry key (MongooseAppID); that's something needed for you to list those ProgId's in drop-down lists under edit mode of WinStudio. If you were building those IDO projects using Object Studio locally, Object Studio is to take care of that automatically, but you may need to do so if you were distributing those new IDO's to some other machines. Here is another document I wrote long time ago for BP's:
Hoping that you got all you wanted to hear...
-----Original Message-----
From: Sharon McGuinness
Sent:Wednesday, October 22, 2003 4:08 PM
To:Kengo Kuwamura
Cc:Jon Bossman; Michael Pastore
Subject:MTS vs. Inproc
Hey Kengo,
I'm received some information from Mike Pastore and Jon Bossman regarding having SL environment running 'In proc' vs. MTS.
Currently I have been told that if I do any mods to IDO's or add new IDO's, I can only test in an 'in proc' environment.
(which is indicated by the fun little icon in my task tray)
Can you provide me with an explanation as to what the differences between the two setups is?
Here is my initial 'dummy' stab at the differences:
MTS - Your .IDO's are installed to use MTS to manage transactions to/from the IDO.
(On my machine, which is MTS setup, I can see all of the SYMIX.SL**** in Component Services / My Computer / COM+ Applications / fsIDO / Components)
In Proc - You IDO's are installed to use the 'registry' on the server to allow visibility to the IDO.
Why can't we use MTS to test our new or modified IDO's?
Feel free to say 'Because I said so' if you don't have time or energy to explain it.
:-)
I just want to understand before I go messing with my precious local environment (messing = breaking).
In an e-mail to Mike about changing from MTS to inproc, you said,"Then, you probably need to get rid of those COM+ applications running on your machine; then, re-register those IDO and other COM objects on your machine using "regsvr32" utility beside using the right version of SymixDB."
When you say 'get rid of' does that mean deleting the entries I see in Component Services?
When you say 'reregister those objects', do you mean those 16 .dlls located in C:\Program Files\Frontstep\SyteLine\IDO?
Do you know what the 'IDORegSvr.exe' (in that same directory) does?
And what does 'right version of SymixDB' mean?
Do you just mean 'if you're registering 7.02.05 versions of the .dlls, then you want to make sure your SL database has the same version?
Thanks for you time!
Sharon
Sharon McGuinness
MAPICS Professional Services
Phone: 607.275.8283
Fax: 678.393.5350
This email and its contents are privileged and confidential information intended solely for use of the addressee. If the reader of this email is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or other use of this message and its contents is prohibited.