Skip to main content

I posted this as a question to IFS via the Customer Engagement Center, but was told it was not “Unfortunately the raised case does not fall within the support scope as this is not a product fault . . . ”, so I would like to post it here in case any of the community has any thoughts or opinion on the matter.

 

During the course of our training, testing and deployment of TouchApps in our non-production environments, we have received conflicting opinions regarding the best practices of database configuration for TouchApps.

1.) Originally, when we worked with IFS, the configuration was to create a separate database dedicated to TouchApps
2.) Later, it was conveyed to us that IFS’s standard configuration for TouchApps was to extend the schema of the IFS database

As we approach going live with TouchApps in production, I would like to discuss this topic with someone very well versed in the pros and cons of these two configurations, specifically:

What impact do both of these configs have on the data "refresh" process (copying current PROD database down to test/dev instances?
Does every "non-prod" TouchApps server need a dedicated database if we do not extend the schema of the IFS database?
What are the performance issues associated with each of these configurations?

Hi @woprhowe ,

 

We decided to install the touch apps as a separate database on our database server.  We installed and configured touch apps in our production and test environments only.  We didn't install it in our development environment because we didn't see the need since we had it in test.

 

We choose this setup because we felt it made copying production to the test and development environment regularly would be easier because we would have to worry about the touch app server configurations.   We do not copy the touch app database from production to test.   We just use RMan to backup production touch app database in case something goes wrong.  We've been running it this way for 2 years and its worked just fine and copying production database to test or development is easy using RMan backup and duplicate.

 

When we upgraded from IFS App 10 Update 8 to Update 15 we updated our Test environment first and since we had touch app database separated if something went wrong upgrading touch app database we would just restore that small database and start again.

 

I also believe the touch app server goes away in the IFS Cloud so you won't have dead schema when you upgrade.

 

Regards,

William Klotz

Nice! Thank you for the quick response and detailed explanation! This helps me move forward!

 

Regards,

Bob 

Hi

I can confirm that Touch Apps server has been sunset in IFS Cloud and that there is a complete other way to deal with the communication between the device and the backend system, which is more inline with how the rest of IFS Cloud works. 

Regards

Johan

Reply


Terms & ConditionsCookie settings