Points of attention

The data refresh functionality can lead to a limited amount of data inconsistencies in the target tenant. To overcome this as much as possible, pay attention to the remarks in this section.

General

  • Avoid data changes as much as possible when the refresh process is running.
  • Not only the application data, but also users and settings are updated and overwritten.
    • Therefore, users that were not previously in the target tenant are now added and they can receive emails from that tenant.
    • If you use other authentication mechanisms than the standard email password, such as Azure AD or Okta identity providers, see the Infor Operating Service Cloud Edition Administration Guide on https://docs.infor.com/. There may be differences in source and target tenants that might require a renewed setup on the target tenant.

LN application-specific

  • We recommend that you set system messages in both tenants to inform users.
  • We recommend that you set the planned downtime in both tenants. This prevents jobs from running.
  • There is an option to set tenants to Admin Only mode. This prevents normal users from logging on to prevent data from being changed.

    If you want to do this:

    • Before the start of the refresh, set the tenants to Admin Only mode.
    • After the refresh has completed, change the tenant back to Operational Mode.

    After a refresh, the target tenant is always set to Admin Only mode.

  • After the refresh, the application version of the target tenant is exactly the same as the source tenant version because an exact copy is made. Before the refresh, the target tenant can have any application version.
  • The ${BSE}/tmp folder in the target is cleaned up. The ${BSE}/appdata folder remains unchanged. S3 folders are not included and are not copied.
  • Extensions, personalizations, and any development work in activities are overwritten in the target. Ensure to back this up if this must be retained.
  • Any developed PMC solutions, which were previously exported, are overwritten with the imported PMC solutions from the source tenant. The original solutions are lost.
  • Often, the CloudSuite Refresh is used to update a test tenant with the data from a production tenant. In this scenario, the production tenant is the source and the test tenant is the target.

    The refreshed test tenant, upon its initialization, could start shadowing the automatic business processes of the production tenant. Examples of such automatic processes include sending emails with invoices and contacting tax authorities through APIs. To avoid this, all automatic processes on the target tenant can be automatically blocked. This is additional to the Admin Only mode. To block these processes, use the Parameters Block Automatic Activities after Cloudsuite/Tenant Refresh (ttmtm5110m000) session on the source tenant before the refresh is started. In this session, you can set several parameters to block the automatic processes. During the refresh, these parameters are applied to the target tenant. See the online help of the Parameters Block Automatic Activities after Cloudsuite/Tenant Refresh (ttmtm5110m000) session.

Infor OS-specific

See the Infor Operating Service Cloud Edition Administration Guide on https://docs.infor.com. This document contains all information on what is and what is not refreshed during a refresh, and what to consider. This document also describes the actions to take regarding the Infor OS components: Infor OS Portal, IFS, ION, API Gateway, and IDM.

Special remarks:

  • During the refresh, no Data Lake data is copied from the source. To get all the data up to date, a full additional initial load is required.
  • Security related information is deleted on the target tenant. Make sure you have backups of the identity provider, service provider, etc. Also make sure you have at least some users with IFS access roles set up to be able to login with Infor OS Portal identities.

Refresh Windows

You can schedule the CloudSuite refresh to start in several available time slots that are predefined per farm:

  • There is a predefined window of up to 4 hours in which the CSLN refresh can be started. The window starts at 9 PM, 11 PM, or 1 AM CET, EST, AET, JST.
  • The number of concurrent refresh jobs is limited per application farm, so a preferred window may not be available.
  • Expected duration:

    The time to perform a refresh depends on the size of the CSLN suite. A refresh can take 2 to 3 hours. The actions on the source tenant take approximately 30-60 minutes.