Forum Stats

  • 3,837,237 Users
  • 2,262,240 Discussions


12c - Naming of multiple report servers and calling from forms

limsguy Member Posts: 8 Blue Ribbon

Hi all,

We're starting a 6i client/server to migration and plan on having the following configuration:

  • Weblogic server for prod
  • Weblogic server for test
  • 5 developer seats with full Weblogic install on each machine

The question is that if we hard code the report server name, say repsever1, into forms then configure a repserver1 on each of the 7 instances, will they interfere with each other on the network? Is it a better idea to have each instance have it's own report server name and write pl/sql code to have the proper one used depending on where the form is running? I've tried to find in the docs if there was a built in way to do that without code but haven't had any luck.

Any help and guidance for this would be appreciated!




  • Michael Ferrante-Oracle
    Michael Ferrante-Oracle Senior Principal Product Manager USMember Posts: 7,294 Employee
    edited Jul 14, 2022 6:42PM

    In my opinion, the best approach is to never hard code something that might need to be changed. A hostname, ip address, or any other object that is at risk of changing in the future should not be hard coded. This should be configuration parameters. For Forms, it is easy to create a parameter (environment variable) and read that value in code.

    For example, in the Forms Environment settings (default.env) add something like this:


    Then in code, you can easily get that value like this:

    TOOL_ENV.Getvar ('REPORTS_SRV_PROD', <variable name>);

    Now you can easily change the config without having to make changes to the application code. You can even go a step further and add a Forms Parameter and pass the desired value in at startup time.

    With this you can add the desired values when you call the app. So something like this:


    In the code, you would use it like this:

    somevariable := :PARAMETER.P_REPORTSERVER;


    I guess the one thing I didn't mention how to set the name in code.


    Michael Ferrante

    Senior Principal Product Manager


    Twitter: @OracleFormsPM

  • limsguy
    limsguy Member Posts: 8 Blue Ribbon

    That makes sense. Hard coding is bound to bite you in the butt at some point!

    We're just getting started with using the forms migration assistant and saw that it was hard coding in the rp2proreportserver parameter so that's where that came from. I guess what we want to do instead is leave that blank and set the value ourselves in code.

    So for the other question we're stuck on is what to set that value to given we'll probably have 7 instances. We don't run all that many reports so we're not anticipating needing more than one report server for prod, but we do want to be sure we configure the test and the devs properly so they don't somehow conflict with production reports. Should we configure the report servers on prod, test, and the 5 developer seats with unique names and then use the env method you mentioned to grab the value for the current running server? Or does that not matter and they all can be configured as repserver1 without any problems?

    As an aside, coming from 6i client server world I'm really liking working with 12c so far. Was a bit of a pain getting the first test install going on my pc but now that it's working it seems to be pretty slick!

    Thanks so much for the quick response!


  • Michael Ferrante-Oracle
    Michael Ferrante-Oracle Senior Principal Product Manager USMember Posts: 7,294 Employee
    edited Jul 14, 2022 9:09PM

    Unfortunately, I would not call myself a "Reports" expert so may not be able to offer much along the lines of best practices. However, I will say this. Naming each server something different is important especially if all the machines are on the same subnet. By default, Reports will broadcast on the network to find a particular server. So if there are more than one with the same name you likely will have issues. At least, that's how I recall it to work.

    Regarding the use of FMA (Forms Migration Assistant), unless you are coming from a version older than 6.0.8 I personally would make every possible effort to manually make any needed changes rather than use the tool. In the case of Forms modules that previously used the built-in RUN_PRODUCT, the FMA will attach rp2rro.pll to all modules that do that and add wrapper code to essentially convert RUN_PRODUCT to RUN_REPORT_OBJECT. Although this has successfully worked for many years and many customers it does add another layer of code that you will forever have to maintain. Again, it does work well, but does add more weight and complexity to your applications.

    Speaking of v12, the number of improvements that went into 12 compared to v11 (the previous family) is extensive. So for you, coming from 6 the amount of improvement will be tremendous. Unfortunately, we have customers who often upgrade for the sake of upgrading or because of system compatibility issue but, do not take advantage of what the new versions offer. In other words, their applications that were previously designed in Windows NT4 days still look like that even after upgrading and they make little or no effort to change it. I strongly recommend that some amount of development effort be offered to these applications in order to improve them. Doing so will make users happier and potentially more productive.

    If you have not already seen the Forms 12c New Features guide, I recommend at least skimming through it. As I mentioned, it was written from the perspective of the previous version family (11gR2). The doc covers dozens of improvements, some of which are trivial to implement and in some cases do not even require code changes. Just config change(s).

    We are planning one last release in the v12 family, but from a Forms point of view it will have only a few improvements although some may be considered significant to some people.

    That said, the next major release (planned for availability in 2023) is expected to have lots of improvements, most focused around providing ways to make your applications look and feel more modern. There are certainly other features planned, but UI and runtime in general are the focus. More about those plans can be found in the Statement of Direction for Forms.

    If you want see occasional sneak peaks at what we're working on, feel free to follow on Twitter: @OracleFormsPM or check out this hashtag on Twitter: #OracleForms

    Michael Ferrante

    Senior Principal Product Manager


    Twitter: @OracleFormsPM

  • ben_g
    ben_g Member Posts: 33 Blue Ribbon

    Regarding "if there are more than one with the same name you likely will have issues" in that case the first server on a subnet which starts up reserves the configured name. Other servers with the same name will start but are blocked from receiving any requests and your Forms processes will be talking to a reports server you're not expecting, such as one in a different domain or on a different server.

    @limsguy a few other things for you to consider:

    There are two ways Report Server can be configured during installation: Stand Alone or In-Process. Make sure you read Doc ID 274936.1

    If your dev PCs are on Windows then I really recommend you install the F&R development stack on a VM. Some people find the installation and config challenging, and if it goes bad and they need to start over rebuilding a VM or restoring it to a checkpoint is a lot easier that reimaging your PC and losing everything.

    Also if you are on Windows it's not a good idea to try and install two different versions of the tools at once, so consider what you'll do when it's time to upgrade to the next version of FMW. I have two VMs, one with which we have just finished migrating off of and the other with which all our Prod systems are finally on. Whenever arrives I will delete the VM with and install the new version on a clean copy of Windows, and at no point will I have done anything to impact all the other software I have installed on my PC. I can rebuild a VM with F&R and get the test.fmx running in a couple of hours, I just swapped to faster hardware and it took several days to do my main PC.

    Aside from the initial configuration following installation, I never start the Reports Server on my dev VM and only run reports there from the builder.

    It's not clear from your OP but are you going to have a server environment for dev? If not you should consider one, if you've got a non-prod server to run test you can also run dev there in a different domain.

    Consider where you are going to compile the F&R modules which you'll release to Prod. Oracle recommend you compile everything in each environment but I haven't worked anywhere which does that for Prod. Where I currently work we compile in dev (which is either Oracle Linux or Solaris), create a tar of that build and check it into source control. In the higher environments we have scripts that get a specific build from source control and untar it, completely replacing the entire client for the app.


  • limsguy
    limsguy Member Posts: 8 Blue Ribbon

    Thanks so much for all the input. Lots to think about and it's brought up several items we hadn't considered. Certainly saved us tons of future grief!

    The reports server issue is a big one and we certainly want to get it right the first time. Passing the report server name through the form parameters would mean a ton of additional code changes since the application is structured with open_form and call_form off a central menu, and worse, some forms in turn call others, so each of those calls would need to be changed to pass the parameter. Since we have to add code in place of all the run_product calls anyway, I guess the best bet would be to dynamically figure the server from either a lookup table or a simple env variable at that point.

    @ben_g "if you've got a non-prod server to run test you can also run dev there in a different domain." So do you mean setting up a dev domain on the test server in addition to each developer's local instance, or instead of each dev having their own locally? We're planning on a Windows server so the hope was we could: check out from source, develop and compile locally, move to test, then move to prod, and finally check in to source from local machine. I guess if there was an issue with compiling on Windows 10 and deploying to a Windows server, we would just add a recompile step on the test machine since it's going to be the same as prod. Of course, if we have to compile on the server then the whole reason for running on Windows server goes away. I would have preferred a Linux server but that wasn't my call :-)

    We had considered using VMs for ease of setup, since while this migration is all happening the devs are still busy with their normal workload. But we hadn't considered the impacts on upgrades and patches though and that's where I can see a VM would be a huge advantage over a native install. Definitely going to push in that direction if we can.

    Thanks again for all the help!


  • ben_g
    ben_g Member Posts: 33 Blue Ribbon
    edited Jul 19, 2022 10:55PM

    WRT "Passing the report server name through the form parameters would mean a ton of additional code changes", you should have a function to execute a report and monitor the reports server for its result (to display or whatever) in a form library. The library does TOOL_ENV.Getvar as Michael wrote and none of your forms need to care how that is implemented.

    Every Forms app I've worked on has a collection of libraries, some with a massive amount of functionality written over 20+ years, and I suspect you'll be writing a lot of them with the change to a 3-tier architecture.

    Yes to "dev domain on your non-prod server". Dev PC/VM is only to use the development tools, source control and debugging etc. When you are making breaking changes or experimenting with configuration, can you afford to have your test domain unavailable? If you only have test then you only have one server environment where you can play and the first time you deploy anything new it's going to your Prod environment so you are adding risk.

    Separating your concerns by integrating new content into dev and then doing your first release into test is a great way to catch errors in your scripts or release processes without breaking Prod. That's got nothing to do with Forms it's just good practice.

    This is just an observation but I've never worked anywhere that uses Windows for their FMW or DB servers.