IFS Cloud Clone

Hi @Darshana Herath 

you have to create an IFS case to do this because you aren’t able.

So in IFS Cloud if we want to copy our LIVE/PROD environment to our TEST use-place environment we can not do so - and have to get IFS to do this?

This doesn’t seem right - how can we have a realistic TEST environment? Is it only IFS that can do this - or could a Partner.

To confirm, are you cloning cloud to cloud?  Or cloud to on prem?  Cloud to cloud is a ticket and it is very easy.  Takes them about 4-5 days to complete.  Cloud to on prem...that is much, much more difficult.  I can explain what we went through but as far as I’ve been advised, there is no official procedure.

All our environments are in cloud. If we want to create a copy we have to create an IFS case. This is the process I know. Maybe they have other process but I don’t think so.

Hi, 

We have our environment IFS Cloud on prem. Do you have any idea about the procedure on prem to on prem?

Thanks,

Hi @gianni.neves 

If it is on prem then you have do it by yourself. Because IFS doesn’t access to your (local) server and make the copy. 

For prem to prem - you should be able to do this in house with a good DBA and an IFS admin per your normal cloning / refreshing procedures.

For cloud to on prem refresh you’ll need to:

1. Define a pathway to receive large file transmissions from the cloud to your on prem environment - this was particularly challenging for us and the cloud team is incredibly unhelpful here.  The FTPS (or SFTP) pathways defined in your COG do not seem to support the transmission from IFS to customer...only customer to IFS.  
2. Request a backup of the source environment via a ticket for the cloud team.  I would request this with the assistance of a good DBA as the source database will likely need to be split up in a way that your DBA can put back together.  We struggled here as well as instructions that made sense for us were not documented as part of cloud procedures so the cloud team wouldn’t do the split in a way that we could put back together.
3. Perform some application and middleware configuration after the refresh 

Hi Darshana,
If you have a IFS Cloud services contract, i.e. everything fully managed by IFS (so, not on premise), you do not have any access to the Oracle database in the Use Place at it is in their private cloud.

If you want for instance PRD envt to be cloned to UAT, at the moment you have to open a “classical” case for that in the customer portal.
Be careful because the time slots IFS provides for those kind of jobs are limited and you have to book your cloning activity I would say at least 2 weeks in advance. I regularly struggle with them to respect the schedule I need.
A dedicated page to ask for that kind of job should be available soon in the Cloud Services tab of the customer portal.

One more schema!

FYI, we have found that it works best to ALWAYS export IFSIAMSYS before cloning and import this back afterwards. In other words, would suggest treating the IFSIAMSYS schema as a “refresh exclusion table” and not as a “refresh exclusion table for security” (above).

Here are a few more tables that I would add to the Refresh Exclusion List

Refresh Exclusion Tables Additions...

35. ifsiamsys schema - this is mentioned above, needed to retail Azure SSO/environment.
36. routing_address_runtime_tab
37.  fnd_branding_tab - this and the next 4 tables including brading, banners, etc. We separated these by environment with separate labels at top so users can tell which one they are in.
38.  fnd_branding_property_tab
39.  fnd_branding_resource_tab
40.  fnd_branding_token_tab

What about systems using a PSO Workbench connection? Where are the PSO connection details located in the database?

It’s stored in 32. scheduling_config_tab above.

Specific settings for the Scheduling Configuration used by Service Management are stored in 33. svcsch_configuration_tab above.

We are on IFS managed Cloud and are using the automated cloning options via SNOW.

Has anyone experienced that when taking a clone of PRD, it affects the performance of the source system, in this case PRD?
The Cloning is set to take 10 hours, so for a global company with 24/7 operations, there is never a good time to have something disturb PRD,

Br Hans

@IWAHANS cloning done in a traditional way could have a performance effect.

I don’t have the details of managed cloud cloning options, but for remote deployment (‘on-prem’) installations run in the Azure cloud it is possible to take an Azure snapshot of the database VM disk, and spin up a completely separate clone VM using this disk.
Azure snapshots seem to be instantaneous so we experienced no performance effect for the source system. The clone VM could then be used to perform heavy database operations such as exporting or cloning without an effect to the source system. Running a remote deployment misses out on much of the automation though, and makes the customer responsible for much of the technical management.

If the DB in managed cloud is not run as a separate VM this may not be possible there technically - nor it is a managed cloud offering on a commercial level as more resources are needed for an extra VM, even if temporary.

It seems that

41. SCHEDULING_DATASET_TAB

should be added in systems with PSO usage, in order to preserve the datasets configured.

The whole list then becomes:

 

Refresh Exclusion Tables

1. brbase_property_tab
2. common_messages_tab
3. config_instance_param_tab
4. config_instance_tab
5. connect_envelope_tab
6. connect_print_agent_task_tab
7. connect_queue_tab
8. connect_reader_tab
9. connect_sender_tab
10. connect_server_tab
11. connect_simple_routing_tab
12. connect_transformer_tab
13. custom_connector_library_tab
14. custom_reader_param_tab
15. custom_sender_param_tab
16. edm_location_tab
17. edm_location_user_tab
18. fnd_monitor_category_tab
19. fnd_monitor_entry_tab
20. fnd_setting_tab
21. media_archive_tab
22. plsqlap_environment_tab
23. remote_assist_group_user_tab
24. remote_assistance_customer_tab
25. remote_assistance_group_tab
26. remote_assistance_user_ab
27. report_plugin_settings_tab
28. routing_address_tab
29. routing_rule_address_tab
30. routing_rule_condition_tab
31. routing_rule_tab
32. scheduling_config_tab
33. svcsch_configuration_tab
34. tm_serve_parameters_tab
35. ifsiamsys schema - this is mentioned above, needed to retain Azure SSO/environment.
36. routing_address_runtime_tab
37.  fnd_branding_tab - this and the next 4 tables including brading, banners, etc. We separated these by environment with separate labels at top so users can tell which one they are in.
38.  fnd_branding_property_tab
39.  fnd_branding_resource_tab
40.  fnd_branding_token_tab
41. SCHEDULING_DATASET_TAB

Refresh Exclusion Tables for Security

Excluding these additional tables will leave your security ‘as is’ in your cloned environment instead of overwriting it from the source. (nowadays overwriting means all of the local passwords will get corrupted due to different cipher salts - not a problem with SSO, but an issue when using local accounts)

1. fnd_bpa_grant_tab
2. fnd_grant_role_tab
3. fnd_proj_action_grant_tab
4. fnd_proj_ent_action_grant_tab
5. fnd_proj_entity_grant_tab
6. fnd_projection_grant_tab
7. fnd_role_tab
8. fnd_user_role_tab
9. ifsiamsys
10. pres_object_grant_tab
11. system_privilege_grant_tab
    
     

I am not aware of any official documentation or R&D input to this list, it has been found working in practice.

For any persons referring this post, following post will be also helpful.

 

Has any documentation been created for cloning databases on premise? I’m not sure if the list has been updated recently.

So far Useful,

Schemas:

1. IFSIAMSYS

Tables :

1. BRBASE_PROPERTY_TAB
2. COMBINED_FLOW_TAB
3. COMMON_MESSAGES_TAB
4. CONFIG_INSTANCE_PARAM_TAB
5. CONFIG_INSTANCE_TAB
6. CONNECT_ENVELOPE_TAB
7. CONNECT_PRINT_AGENT_TASK_TAB
8. CONNECT_QUEUE_TAB
9. CONNECT_READER_TAB
10. CONNECT_SENDER_TAB
11. CONNECT_SERVER_TAB
12. CONNECT_SIMPLE_ROUTING_TAB
13. CONNECT_TRANSFORMER_TAB
14. CUSTOM_CONNECTOR_LIBRARY_TAB
15. CUSTOM_READER_PARAM_TAB
16. CUSTOM_SENDER_PARAM_TAB
17. CUSTOMER_ADDRESS_RUNTIME_TAB
18. CUSTOMER_CONNECTOR_LIBRARY_TAB
19. CUSTOMER_READER_PARAM_TAB
20. CUSTOMER_SENDER_PARAM_TAB
21. DEMAND_USER_ACCESS_RIGHTS_TAB
22. EDM_LOCATION_TAB
23. EDM_LOCATION_USER_TAB
24. FLOW_WEATHER_TAB
25. FND_BRANDING_PROPERTY_TAB
26. FND_BRANDING_RESOURCE_TAB
27. FND_BRANDING_TAB
28. FND_BRANDING_TOKEN_TAB
29. FND_MONITOR_CATEGORY_TAB
30. FND_MONITOR_ENTRY_TAB
31. FND_SETTING_TAB
32. FNDCN_CONDITION_PART_TAB
33. FNDCN_CONFIG_PARAM_INST_TAB
34. FNDCN_CONFIG_PARAM_TAB
35. FNDCN_ROUTE_ADDRESS_REF_TAB
36. FNDCN_ROUTE_ADDRESS_TAB
37. FNDCN_ROUTE_CONDITION_TAB
38. FORECAST_CUST_FIELD_SETUP_TAB
39. FORECAST_DB_IDLE_TAB
40. FORECAST_FLOW_TAB
41. FORECAST_SCHEDULE_TAB
42. FORECAST_SERVER_CONNECT_TAB
43. FORECAST_SERVER_PARAMETER_TAB
44. FORECAST_SERVER_SETUP_TAB
45. FORECAST_USER_TAB
46. GROUP_FIELD_LIST_TAB
47. HIST_EXT_INVENT_PART_ISSUE_TAB
48. MEDIA_ARCHIVE_TAB
49. PERIOD_VERSION_DETAIL_TAB
50. PERIOD_VERSION_HEADER_TAB
51. PLSQLAP_ENVIRONMENT_TAB
52. REMOTE_ASSIST_GROUP_USER_TAB
53. REMOTE_ASSISTANCE_CUSTOMER_TAB
54. REMOTE_ASSISTANCE_GROUP_TAB
55. REMOTE_ASSISTANCE_LOG_EVENT_TAB
56. REMOTE_ASSISTANCE_LOG_TAB
57. REMOTE_ASSISTANCE_USER_TAB
58. REPORT_PLUGIN_SETTING_TAB
59. REPORT_PLUGIN_SETTINGS_TAB
60. ROUTING_ADDRESS_RUNTIME_TAB
61. ROUTING_ADDRESS_TAB
62. ROUTING_RULE_ADDRESS_TAB
63. ROUTING_RULE_CONDITION_TAB
64. ROUTING_RULE_TAB
65. SCH360_CONFIGURATION_TAB
66. SCHEDULING_CONFIG_TAB
67. SCHEDULING_DATASET_TAB
68. SVCSCH_CONFIGURATION_TAB
69. SYSTEM_FORECAST_TAB
70. TM_SERVER_PARAMETERS_TAB

​@Binujaya Rajatheja and ​@SamiL we cloned our Cloud environment in December for the 1st time after going Live, and we used this article as the basis for tables etc to exclude. 

We are PSO user, and since the clone our PSO TEST environment was not updating. A support case was raised, and after investigations they believe the cause could be the fact we excluded the SCHEDULING_DATASET_TAB during the clone. The field ‘Last_Change_Log_Id’ gets updated and the fact we exported this table before the clone, and imported it back into TEST after meant there was a disconnect with the values stored in this field which is referenced in the core logic. 

Therefore support have advised that we shouldn’t include SCHEDULING_DATASET_TAB in the export list.

In that case the dataset surely needs to be recreated.

Would it have been resolved just by resetting the connection? Ie. from the cloud side, disable the dataset, disconnect the configuration, then connect and enable.

That is surely necessary regardless to get everything flowing after a clone.

​@SamiL No, I think the field ‘Last change log id’ gets updated each time a Change message is produced; so this sequence number being out of sync with other parts of the system was the cause of no changes being sent to PSO. 

We tried de-activating and re-enabling the dataset as part of our troubleshoot but this didn’t fix the issue.