5 Replies Latest reply on Jan 14, 2013 10:42 AM by Ady Keeling

    How does your shop administer your development team's environments?

      Please forgive if this is the wrong forum for this question. I think this forum makes the most sense for it, so here goes. I posted this in a MOS community but did not get hardly any feedback.

      I am curious how others out there are handling there developer installations. We have Oracle Forms and Reports version 64bit running on Solaris SPARC with WLS 10.3.6 for for production and test. We have around 15 developers who are currently running WLS 10.3.4 and Forms and Reports on Windows 7 32 bit. At the time we made our conversion from 6i to 11g Oracle Forms and Reports were not supported on a 64 bit Windows platform. That has since changed.

      My issue is maintaining all of these separate installations for the developers. Because they are 32 bit there is the 4GB of memory constraint on the operating system. I have lots of trouble with these instances in large part due to the tight memory configuration. Just running WLS with two managed servers, one for forms and one for reports uses 75% of the available RAM.

      What I would like to do is have some sort of shared development environment so that I don't have maintain so many instances of WLS and Forms and Reports. I am curious how other customers are handling their developer installations. Is there a better way than loading a full blown WLS and Forms and reports server on each developers workstation? I would love to load a 64 bit Windows 2008 server with WLS and Forms and Reports, and give it Terminal server licenses to allow them to share one instance, but I don't see where Forms Builder and Reports Builder are supported on 64bit Windows server platforms, at least not 11gR1.

      My last resort is to add memory to their workstations and reload as 64 bit, but that does nothing to address my problem of having to maintain so many instances of WLS and Forms and Reports. I am prepared to go this route if I can not find a better solution. I also understand there is a developer edition now available where the forms and reports run inside the admin server reducing the footprint, but I am not sure which version this is included in.

      So again I ask how are you folks handling you Forms and Reports installations for your developers?

      Edited by: user11049532 on Jan 11, 2013 10:23 AM
        • 1. Re: How does your shop administer your development team's environments?
          Ady Keeling

          We're running forms 11gr2 on win 64bit server. The developers all run win7 64bit with 8gig of ram. We have a development weblogic server, which each developer has a forms config profile for. This profile has the developer's directory on the server as the path for forms along with a shared directory for forms 'released' to the development environment. The developer's server directory is mapped to a drive on their pc, and they store the forms and libraries they're working on there. A developer doesn't run weblogic on their pc, instead their runtime settings in forms builder point to the config on the development server, so the dev server runs their forms when testing.

          Doing it this way means all forms can be run and tested on a proper server with the right amount of ram, leaving the developer's pc with enough ram to spare.

          Hope this helps,

          Edited by: Ady Keeling on Jan 11, 2013 8:57 PM
          1 person found this helpful
          • 2. Re: How does your shop administer your development team's environments?
            That sounds like a really good answer. I don't quite follow the details of how you achieved it, but that is the kind of thing I am looking for. Did you read about this somewhere, where maybe I can get more details on how exactly this is setup, or did you architect this solution yourself?
            • 3. Re: How does your shop administer your development team's environments?
              Ady Keeling
              We worked this out ourselves, mainly because we had the same problems as you.

              Another way to do this, albeit a bit more work for the developer, is to not test the forms from within the forms builder, but to build a form then 'release' it onto the development server, and test it from there.
              When I say release, I mean copy the file onto the server and compile it on that platform in a directory that is in the forms path of the development weblogic server.

              We used to run Linux for the servers and used this sort of config. We had scripts written that would release the forms and compile them using scp/ssh. As we now develop and deploy on the same win64 platform, we can simply compile the form inside the builder and this automatically saves it on the server if it is opened from a network share.

              Sorry if this isn't very clear, but it's not very easy to explain, and as it's late on friday evening I'm not at work so haven't got easy access to stuff to check things until Monday.

              If there's something specific you don't understand just ask away.
              • 4. Re: How does your shop administer your development team's environments?
                Unfortunately, I have a lot of questions. I will ping you back in this thread on Monday if you don't mind. If you don't time to answer them, no worries. I am thrilled that this is even possible. I am going to go ahead and start loading a Windows 64 bit server with a basic WLS and Forms installation. I might be able to figure this out myself, but I will probably be back asking for clarity on a couple of things.
                • 5. Re: How does your shop administer your development team's environments?
                  Ady Keeling
                  Right, I've had a look this morning and here are a few gaps in my explanation:

                  Each developer will need their own environment set up on the development server.

                  The first part of this is to have their own directory on the server which they may want to map to a drive on their PC. Let's call this directory DEV_HOME.

                  The second part is to set up their environment on the Forms server part of weblogic, you can do this either through the Enterprise Manager interface or manually via the filesystem. If you're doing it via the file system the files you need to copy/alter will be in a directory similar to the one below:


                  First of all make a copy of the default.env file for each developer. You will need to change the FORMS_PATH variable in this file to include the developers DEV_HOME server directory. In our setup my environment file is called adrian.env.

                  Next you will need to change the forms web configuration to include a section for each developer. If you're doing it manually the file is called formsweb.cfg and will be in the directory listed above. All you need to put in the section is a variable 'envFile' pointing to the environment file you've just created. The section for me in our formsweb.cfg is listed below:

                  *# System parameter: file setting environment variables for the Forms runtime processes*

                  You may need to restart the forms server to have these changes take effect if you've done the changes manually.

                  The developers should store all their forms files that they are working on in their DEV_HOME directory on the development server. When they open a file in Forms Builder they should open it using the full network path (not via a mapped drive) e.g. \\DOMAIN\Server\d$\users\username\fmb\myform.fmb.

                  In Forms Builder the Application Server URL needs to be set, it can be accessed by:

                  Select Edit from the menu -> Preferences... -> Runtime -> Application Server URL

                  This setting needs to be changed to:


                  Now when a developer clicks the Run form icon the form should run on the development server, with no need to have weblogic running on their own pc.