Skip to main content

We have on-premise IFS TouchApps running fine in production (Apps10 UPD5 TouchApps Server version) and need to install a new Test environment on the same server.

When running IFSTouchAppsServerInstaller.exe to create the new TouchApps environment the installer values default to contain the existing production Touchapp server values.  If we change the settings on the first screen to point to the test database instance for the deployment, and then use the ‘Test Connection’ option to  make sure all is OK, this works fine.

However the problem happens on the next screen where the System ID is also set to the Production value but cannot be changed (it is showing as a read only field).  

How can I remove or change this value, or where can I find/clear the old configuration that the installer executable uses to remember these old settings?

Right now I am unable to install a new test environment on the server unless it is given the same System ID as the current production System ID, which is a really bad idea...

To be clear, this the screen where all of the values are coming in preconfigured from an existing TouchApps instance when trying to create a new one:

All of them are changeable so I can set those as needed EXCEPT the System ID which is a read-only field, and without changing that I run the risk of impacting the Production TouchApps instance (which is the set of values that are being pulled in from somewhere)

If I understood correctly what you need is a new system for the test environment. You don’t need to run the installer again in order to do this.

  1. Login to the Touch Apps Server web portal.
  2. In the Customer portal, click Add System link at the bottom of the page.
  3. Specify the values for the Test environment and save.

@Dar Thanks, we can look at that, but our current Test environment isn’t working properly (hence the need to create a new one) so we could only do that suggested process from within the Prod environment.  My guess is that might not work (adding a Test system from Prod) and could be risky?

We also do not want to run Test on the same port as Prod, so that would be another reason to run Test in a separate installation.  What you suggested above might give us something for short-term internal testing but adds risk in the longer term.

I found where those  values are coming from and was able to successfully run the installer.

I needed to clear the single record in the SERVICE_INSTANCE_TAB in the schema used for deploying the TouchApps Server admin info to Oracle.  This contained the Production TAS details from where the Test database had been refreshed from Prod.  Once that record was removed the installer ran and only showed the real ‘default’ values which were fully editable to allow us to proceed.

 

Nick, If you wanted the TAS to use the Test env instead of the Production you could have added the Test system in the customer portal and remove the production system without directly going to the database and editing the table data.

Hi @Dar .  What you suggested would only work if the existing Test Touchapps environment was running successfully and showing the production System ID.  In our case the existing Test touchapps instance was not functioning correctly (because of this issue) so there was no way to connect to it to make that change.

I would also have to do some serious testing before removing the (incorrect) Prod System ID from a Test touchapps server in case it somehow impacted the real production configuration, but perhaps there is no real risk here if they are totally separate… either way it wasn’t something I could do as an option.

Also, if I ever want to install a new Test Touchapps environment on a different server where one does not exist, I think the only way to make that happen would be to clean up the tables first if the database is a copy with an existing TouchApps System ID… otherwise the same non-editable values will come up from the DB and not allow the clean install to get the desired new System ID

Terms & ConditionsCookie settings