Skip to content

Developing Code for Reduced Downtime Deliveries

Note: This feature will be available with IFS Cloud 25R2 GA. However, any preparation work required needs to be done starting from EA.

Uptime Maximizer refers to the strategic and technical approach aimed at ensuring software systems remain operational and available to users with minimal or no disruption during maintenance, updates, or enhancements. This concept is especially critical for organizations that operate in 24x7 environments, such as aviation, finance, and global logistics, where downtime directly impacts business operations, revenue, and customer trust.

Maximum uptime for deliveries is key to supporting 24x7 business operations. With IFS Cloud 25R2 and later, it is possible to apply updates with only a few minutes of system unavailability regardless of whether it's a small customization, a service update, or a release update.

Business Benefits of Reduced Downtime Deliveries

  • Continuous Operations: Keep mission-critical applications running even during updates.

  • Improved User Experience: Avoid disruptions to customers and internal users.

  • Greater Agility: Deliver changes and improvements more frequently without scheduling lengthy outages.

  • Risk Reduction: Limit the exposure to failures that can occur during complex update procedures.

Key Principles of Reduced Downtime Deliveries

  1. Minimized Downtime Windows - Updates are designed to be applied within very short timeframes, often just minutes, so systems can quickly return to full operation.

  2. Live System Compatibility - The system remains accessible during most of the update process, with only a brief interruption for critical switchover steps.

  3. Staged Data and Configuration Changes - Data and configuration updates are staged and activated only when the updated system is ready, ensuring consistency and preventing runtime conflicts.

  4. Scalable Across Update Types - Whether it's a minor patch, a service update, or a major release, the approach to delivering updates remains consistent and optimized for uptime.

System Availability

System unavailability, or outage, can be either:

  • Planned: Includes pre-agreed tasks like patching or maintenance.
  • Unplanned: Unexpected events such as infrastructure failures or critical application bugs.

For some industries such as global enterprises or airlines, maximum uptime is critical to ensure uninterrupted operations.

Objective of Reduced Downtime Deliveries in IFS Cloud

The goal is to minimize the downtime customers experience when taking deliveries including release updates, service updates, and customization changes. Achieving this requires improvements across multiple areas of the application and delivery process, particularly in how updates are applied to the database.

Following are some prominent changes to how different deliveries will be carried out on account of the uptime optimization support.

Pipeline Improvements

The delivery pipeline automates update tasks, including taking database backups. Outage begins once the pipeline starts and system access is blocked.

Optimizations include: - Running certain steps before the system is taken offline - Parallel execution of tasks - Reordering tasks to eliminate waste and reduce downtime

Changes in Handling Background Jobs

To reduce outage: - Background jobs should be terminated after a short grace period. - Jobs must be designed to handle abrupt termination safely to avoid inconsistent results.

For more information on changes in handling background jobs, see Handling Background Job Execution

Changes Required for Delivery Optimization

Applying a delivery to the database DDL, DML, and package deployments, takes the most time. This is one of the main areas which is optimized with the uptime maximizer changes.

Changes to Deployable Code

Certain deployable code must further be changed to support applying updates while the system remains active. This change needs to be made regardless of whether you are planning to utilize the uptime maximizer or not. Some examples are as follows:

  • Reporting Definitions: Users may be using an old version while a new one is applied. These changes must be made to avoid runtime errors.

  • Master Data or Basic Data: Should only be effective once the new application version is active.

Application Behavior During the Delivery Installation

To ensure consistency during the delivery installation, certain functionality such as changes to configurations, system parameters, and other areas where data can be changed by the incoming delivery will be restrcited. These are dynamically applied based on what is in the delivery.

Further, background job executions are gradually disabled in order to avoid having background jobs executed when the cutover starts. In the first phase, scheduled database task and deffered calls are submited to a queued state. However, any urgent jobs defined by the application will execute. In the second phase, any urgent deferred calls that are tried to be submitted by the logic will start to error out propagating the error back to logic so that the operation will be halted.
The jobs which were queued or killed during the delivery will restart automatically after the cutover depending on the design on the background job. If the jobs were killed and the configuration that enables it to be restartable is true, it restarts. If the configuration is false, then it will not restart. If the job was postponed (queued) without execution, it would start after the cutover.

Similar to the background jobs, the Workflow functionality will stop the execution of Asynchronous Workflows during the cutover. After the cutover, the stopped executions will be added to the queue and resumed automatically as long as the system parameter, ALLOW_EXECUTE_ASYNC_JOBS_FROM_PREVIOUS_VERSION is set to TRUE. If this system setting is set to FALSE, the admin needs to review and approve the asynchronous jobs that need to be executed. For more information, see Asynchronous Workflow Executions.