Home » discuss » Public forums » iMIS Community

Can / Should I do significant iMIS development without an iMIS environment?

Posted June 28th, 2010 by jyoung
|

I am about to begin a large project of retrofitting about 6 applications to use iMIS login accounts instead of our existing custom solution.  If I understand the iMIS stack correctly, all we will need are the iBO assemblies (and some other assemblies) and an iMIS database for the things I will need to do.

I was wondering if it would work and if it would be a good idea for me to use nothing other than the aforementioned assemblies and a copy of a clean iMIS database (plus any changes that come in from those who make changes to the iMIS database schema).  I.e., Visual Studio would be on my machine, the .dll's would be on my machine, and the database could be either on my machine or in on a server or VPC somewhere.  No iMIS installation, Web services, or admin UI's involved.

Of course, I want to _also_ (but less frequently) use a VPC with an iMIS environment to make sure that everything works right.  QA testing will be done here as well.

Will this work?  Is it a good idea?

 

EDIT:

The motivation for this is two-fold:

First, if there is some variable about the iMIS environment that causes some things to work that shouldn't, or other things to not work that should, I would like to know about it.  Testing without an iMIS environment as well as with one will reveal any variables between the two.  I would like to know what about the iMIS environment is required, and how to handle any changes made therein.  A good test harness run without the environment should, in theory, help ensure change-proof software.

The other reason is performance.  I will be running many automated tests frequently, there is limited hardware on the VPC server(s), and there are limited VPC's.  I want to shorten the feedback cycle if possible, catching 80% percent of the bugs via faster unit and integration tests w/o the iMIS environment, and the other 20% with an actual iMIS environment.

‹ *Database deadlocking -iMIS Simple Orders - how do the Trans, Orders, Invoice and Subscription tables link together? ›
login or register to post comments | printer friendly version

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Don't you have it all covered if you've got a VPC with iMIS?

On July 1st, 2010 jbound says:

Not sure I understand your intent.  It sounds like you want to do some iMIS development without having "iMIS" running, but then you indicate that you'd also have a virtual machine with iMIS on it to make sure everything works right.  Doesn't that sort of mean that you've got everything you need to do development, including the front-end client to QA with?

Personally I don't think you should do any development (replete with testing) without the iMIS client front and center. Developing against SQL only is not a good idea, you'll want to test (often) the results of your development via the client.  Having had to support attempts by other developers that had access to iBO and SQL but nothing else, it's not pretty to find out that all the work they did blew up as soon as someone opened up an ID in iMIS.

Just my opinion.

Jake

login or register to post comments

Thanks for your reply.  I

On July 1st, 2010 jyoung says:

Thanks for your reply.  I answered part of it via editing the original post.  In short, yes, the VPC should suffice.

The case you talked about--is that something impossible test without an iMIS environment?

Is the iMIS environment's effect on iBO behavior a black box?

Are my questions making any sense?

EDIT: To clarify, I'm not testing against SQL directly, but against iBO's.  But iBO's require at least database to behave as documented.  I want to know if this behavior is guaranteed with at least a database, or if the guarantee only applies when there's an iMIS environment running somewhere.  How would the iBO know of the iMIS environment?

login or register to post comments

Quirky things can happen

On July 1st, 2010 rrichter says:

When developing for IBO i like to think about it as a way to enter data into iMIS as if someone else did. There are some quirky things thought hat the IBO can do that can really only be seen in the desktop client.

Here are some ways that I have used the desktop client to help with IBO development.

* You get an error getting event description information out of iMIS. (this can be caused by the address entered into iMIS being too long or the country being entered wrong) Looking at the event setup will help to figure that out.

* Paid through dates don't advance on dues until you post the batch. So in order to test the system all of the way through you should login, look at your batch, and go through the posting process.

* Cash accounts for credit card processing and other payflow pro parameters need to be setup correctly. You will likely want to change that in the interface to process credit cards against the test payflow account and should change that in the iMIS desktop.

* You often will want to register someone in the desktop or bill someone at a prorated rate or.... to test your IBO code to make sure you handled those situations correctly. If someone is on credit hold you may not want to let them buy a product.

* if you are editing a contact record where the user defined table is set to auto create but there is not one there then your ibo call will fail. Getting into the iMIS client will help you see those situations.

I remember in the early days creating some issues with storing data in the IBO's. If you do it wrong you can produce a new record that won't pull up in the iMIS desktop. Preferred Mail and Preferred Bill flags will cause those issues if you are not careful.

So those are some of the many things where a desktop client is very helpful in building an "application".

Thanks,

Randy

login or register to post comments

Another perspective

On July 1st, 2010 Bruce Wilson says:

While I agree with what Jake and Randy are saying, I would say that it's very practical to do a lot of development without being "in iMIS".

My laptop has SQL Server, Visual Studio, VMware Server, and no iMIS installed (but I do have copies of the Net\bin folder around).  I have multiple VMs each with their own copy of iMIS, using SQL on the host for their database.  This saves me from putting either SQL or Visual Studio inside my VMs, so they stay small.  The VM looks and acts like one more machine on the network, so it's no problem to "publish" the code from Visual Studio onto the VM, or to browse the staff or public sites on that VM from my host -- even when I'm, say, on an airplane.  I only need Terminal Services when I'm using desktop iMIS.  I could probably do without that part too if I wasn't trying so hard to keep my host machine "pure".

There's clearly no substitute for testing with full blown iMIS.  You can't get around that part, but you can get a lot done in the mean time.

--
Bruce Wilson
Director, Technical Services
RSM McGladrey, Inc.

login or register to post comments

Do you run any tests against the iBO's on your machine?

On July 2nd, 2010 jyoung says:

Thanks for sharing.

Do you run any tests against the iBO's on your machine?

login or register to post comments

Testing iBO on the host

On July 20th, 2010 Bruce Wilson says:

No, I don't "run" any part of iMIS on my host machine, only in the VM guests, so I don't have any question about which version is installed.  To do something like you describe, I map a drive from the host to the guest, copy the files to the appropriate place in the guest, then invoke them through my browser (if web), or I RDP into the guest and run the application there.

--
Bruce Wilson
Director, Technical Services
RSM McGladrey, Inc.

login or register to post comments