Using Developer with Local or Remote IS

, ,
1

Hi,

We are currently in the very early stages of ramping up our wM capability (we are starting with 6.0.1) and I have been trying to sort out which of the following setups is best for our developer stable:

  1. Each developer only runs wM Developer on their workstation PC and connects via the network to a central IS (probably running an AIX server).
    Or
  2. Each developer runs wM Developer, their own IS and maybe a Broker and Oracle instance on their workstation PC.

Obviously the Developer Tool allows either option and they both have good and bad points (technical and financial).

My main concerns are:
*The potential network delay with option 1.
*The potential cost of the “beefy” PCs needed to handle the extra load of option 2.

I am hoping to get some hints on how other sites do things. Are there any “simple answers” that would force us in one direction or the other?

Thanks.
BK.

2

Hi,
The option of each user running an IS on their box doesnt seem to be a good idea. This is going to affect the maintanance and integration of the code developed. You can have a development and a production server. The developers can connect to the development server and create flows and other stuff. When it is ready, you can move the packages to the production server. The developer can have the wM developer and Trading networks console on their box. There can also be a central Oracle database which can have two sets of tables, one for development and one for production. Same is the case with broker.

This is my idea of how things can work. I am sure that experts will pitch in with their ideas.
Thanks and good luck.

3

We currently run with all the developers sharing a single IS instance (on an AIX box) for dev. However, we are planning to move to each developer running IS locally. There will still be a single shared oracle instance for dev.

Performance will be better, as a big reason for Developer’s sluggishness is network latency. Plus, it helps keep some of the clutter out of the package structure that inevitably results as programmers need to install and test various scenarios.