This is just a post to share my appreciation about the way iMIS 15 logs into the database.
In 10.6 each user had an ODBC connection on their machine that connected for the base iMIS applications. It then used an application server for the .NET modules such as Opportunity Management. This has a few advantages, but I feel like it has more liability than the iMIS 15 way. For instance, in 10.6 you could run iMIS and be connected to one db for the Customer Portfolio and a different db for Opportunity Management. This is just hard for users to understand and administrators to own.
In iMIS 15, the connection for everything comes from the application server. The client machine has no knowledge of the database because it gets is connectivity through the application server. This means that you pick a server at login, and you are done.
I know people will respond with..."Well how do I run two versions on the same server?" My answer is you can, but don't. How many versions do you really need? We have a development, conversion/staging, and a production. All of these versions can share the same database server or that can be split as well. I understand this issue, but let’s judge the architecture for what it is. This architecture is a better design, easier to understand, easier to manage, and it opens the door for Unified Login. Unified Login is a huge gain, and it would not have been possible without the major gains in the application server.
I say congrats to the iMIS dev team. You guys did a great job with this technology. This information of course comes from my experience working with iMIS. I am a client, so some of this came through deductive logic. If I am wrong on any area, I urge the dev team to correct me.
To expand...
I'm really glad you like the iMIS 15 login so much better. We tried hard to simplify things and minimize the amount of configuration necessary (and the number of errors possible ;)).
Essentially your description of the process is correct.
To expand, in iMIS Desktop you no longer configure an ODBC connection. Instead, you provide Desktop with one (or more) URLs to an app server (such as http://myserver/imis15). When you enter a logon name and password, Desktop uses that URL information to access the Membership Web Service installed as part of the iMIS Application Server and validate the login. Assuming the login information is valid, Desktop uses the web service again, and calls a method named GetDatabaseInfo. This method takes the application server's database connection information and returns it to the Desktop (either as the MANAGER_dbname login or the iMISUser_dbname login, depending on the user's permissions).
That information is used to construct an ODBC connection on the client PC, which iMIS Desktop uses.
What's interesting about this is because it's all part of the web service, other apps can do exactly the same thing; log in to the web service, then call GetDatabaseInfo to get the connection information. We've tried to make sure that everything we added is useful not just for ASI applications, but for third-party apps as well.