1. Administration Guide
  2. Build/Patch Application

2 Build/Patch Application

This chapter describes the process to build or patch a domain.

Build the MFP Cloud Application from the Bootstrap Domain

This section describes the process of installing MFP Cloud Service from the bootstrap domain with retailer data and generated configuration for the plug-in options. Once RPASCE and MFP Cloud Service are installed in the Oracle Cloud environment, the Administrator will have the option to overwrite and install the domain with GA data or with retailer data. The Administrator also has the option to set the deploy status of application as template or non-template (custom).

Bootstrap Environment

A newly provisioned MFPCS environment is set up with a bootstrap configuration that allows the Administrator to log and access the Online Administration Tools (OAT) interface before the domain has been built. The bootstrap OAT configuration allows only tasks required to deploy an application. Once the domain has been constructed, the domain task and the bootstrap activities will both be available. This allows the domain to be rebuilt from scratch multiple times if needed.

Before building the domain, upload the following files for building/patching to Object Storage using the File Transfer Service. Except for the input hierarchy and data files, the other files are not needed if the customer is planning to use the template GA without any extensibility.

  • Configuration file as mfpcs_config.zip with prefix incoming/config.

  • Interface Configuration file interface.cfg with prefix incoming/config

  • Dashboard JSON file dashboardSettings.json with prefix incoming/config

  • Batch control files as batch_control.zip or individual files with prefix incoming/batch_control

  • Input hierarchy and data files with prefix incoming/input

Note:

If it is non-template, the customer is advised to use the same configuration name as GA and the hierarchy and its dimension names aligning with the GA solution for matching dimensions to allow them to move to GA later with minimal changes and to also enable them to integrate with other planning applications in the future. Though the non-template customer is allowed to use their own configuration name and other dimension names, it will not be easy to integrate with other planning applications.

Build Application from the Bootstrap Domain

The following steps take you through the process of building a customer domain for MFP Cloud Service using the bootstrap domain:

  1. After provisioning MFP Cloud Service, log in to the bootstrap domain as an Administration user.

  2. In the Tasks list, select Administration and then Online Admin Tools. Click Submit a New Admin Task.

    Figure 2-1 Admin Tasks for RPASCE Bootstrap Task

    This figure shows the Admin Tasks for the RPASCE Bootstrap task.

  3. Select the Build Application task and click Next.

    Figure 2-2 Select Build Application Task

    This figure shows the selecting the build application task.

  4. Set the arguments for the task:

    Figure 2-3 Select Build MFP Cloud Service Domain Task Arguments

    This figure shows the task arguments.

    1. Enter the Task Label.

    2. Partition Dimension is defaulted to dept dimension in the MFPCS Template version. If the customer is deploying the application as a non-template version, provide the equivalent dimension name from the product hierarchy equivalent to the level of department. The application will be internally partitioned based on this dimension to allow parallel processing of data in the batch.

    3. Select the Use GA Configuration with no extensibility check box, only if you need to deploy the pure template configuration without any changes, otherwise uncheck this box and upload the new configuration to the Object Storage. If no configuration is found in Object Storage, the deploy job will fail.

    4. Select the Use GA data option only if the customer wants to deploy the application using the GA data set readily available for the application. If the customer wants to deploy and use their own data set, upload the files to Object Storage.

    5. Specify the JSE Jar files names if the customer is planning to use new special expressions within the configuration and the JAR file names containing those expressions to be registered. If the customer is providing these file names, they should also upload the JAR files to Object Storage.

    6. If the application was already created and needs to be overwritten, select the Overwrite Existing Application option; otherwise, do not select this option. Selecting this option will drop the existing application and all associated meta data stored, so it will also lose connection to the environment. The customer will need to log out and log in again to view the status of the deploy.

    7. RPAS_TODAY is an optional parameter. It is needed only if the customer is planning to use the GA data set. For MFP GA data, the preferred RPAS_TODAY date is 20230101.

    8. Select the Batch Task Group to run after Application Build. This is an optional parameter and if the template and GA dataset are used, the batch task to run is postbuild.

      If it is a template and non-GA dataset, the customer can either use set_rdx to enable RDX, or run post_hier to enable it and load/import hierarchy files. Or the customer can run postbuild_rdx to enable RDX and then run the postbuild with the customer data.

      If it is a non-template deploy, the customer can provide the batch task name that they want to run after the application build.

      Application Deploy without any batch will not load any hierarchy or data into the application, so the customer may need to run tasks to load hierarchy and data after domain build if they are not providing any task to run during the Application Build.

  5. Select the time to schedule the task and click Next. Click Run ASAP if the Administrator wants to run the task now or the task can be scheduled by selecting the Run on a Schedule option.

    Figure 2-4 Schedule Task

    This figure shows the Schedule Task screen.

  6. Review the selections and click Finish.

    Figure 2-5 Verify and Confirm Selections

    This figure shows the screen to verify and confirm the selections.

  7. After submitting, review the status of that task in the dashboard similar to any other standard administration tasks.

  8. After the task is successfully completed, log out and log in to the application to view the additional tasks specific to the newly built domain.

    Note:

    Users will not be allowed in the application while building and patching the domain.

Patching the Application

This section describes the process of patching the MFP Cloud Service application using the Online Administration Tools. Once the RPASCE and MFP Cloud Service upgrade patches are installed in the Oracle Cloud environment, the MFP application will be patched by default with the latest configuration if the application type is template with the last used plug-in options or use the last used extensible configuration, if it was uploaded by the customer. However, if the customer wants to reapply the patch with changes to the plug-in option, use an updated extensible configuration, or if the customer version is non-template, then the customer can use this task to patch the application.

Before scheduling this task, the Administrator should ensure that no users are logged in to the application while patching the solution. The customer also should upload the configuration if the customer is not using the template version or if using the template version but using extensibility. If the customer has not uploaded any configuration, it will try to use the last used configuration during the application build or the one used during the last patching.

The following steps walk you through the process to patch the MFP Cloud Service application as an Administration user:

  1. After deploying MFP Cloud Service, log in to the application as an Administration user.

  2. In the Tasks list, select Administration and then Online Admin Tools. Click Submit a New Admin Task.

    Figure 2-6 Admin Tasks for RPASCE Bootstrap Task

    This figure shows the RPASCE Bootstrap task.

  3. Select the Patch Application Task and then click Next. Then select Patch Application in the available list of tasks.

    Figure 2-7 Select Patch Application Task

    This figure shows selecting the Patch Application Task.

  4. Set the arguments for the task:

    Figure 2-8 Select Patch Application Task Arguments

    This figure shows specifying the arguments for the task.

    1. Enter the Task Label and Offline Mode Message.

    2. Specify if any new JAR files that need to be registered for any changes to the application configuration as part of the Patching process. The customer should also upload any new JAR files containing that special expression.

    3. After choosing all the necessary options and Log level, click Next.

  5. Select the time to schedule the task and click Next. Click Run ASAP if the administrator wants to run the task now or the task can be scheduled by selecting the Run on a Schedule option.

    Figure 2-9 Schedule Task

    This figure shows scheduling the task.

  6. Review the selections and click Finish.

    Figure 2-10 Verify and Confirm Selections

    This figure shows the Verify and Confirm screen.

  7. After submitting, review the status of that task in the dashboard similar to any other standard administration tasks.

Template Status

The MFPCS application when provisioned will be deployed as a Template application with the Template status of Activated. The customer has the option to deactivate the template status meaning it is a fully custom configuration. If it is a custom configuration, the customer should upload and completely maintain the configuration. Regular upgrades or patches will not patch the application and only upgrade the server version.

The following task can be used to activate/deactivate the template status of the application. It is advisable for the customer to decide on the template status before the application is built for the first time. Later, it may be easier to convert from the template to the non-template version without any limitations. But it will not be easy to move from a non-template version to template, if the configuration does not follow the extensibility rules for the template version of MFP Configuration. See the Oracle Retail Merchandise Financial Planning Implementation Guide for extensibility guidelines for the MFP template version; only if the non-template application follows those guidelines can it be converted to template.

The Template Status changing task is available as a Bootstrap task together with Build Application. In the Change template status drop down, select the Activate or Deactivate option to toggle the template status option and submit the task to change the template status. Activate means it is a template. Deactivate means it is a custom (non-template).

The customer can also use the same task and choose List template status to view the current template status of the deployed application.

Figure 2-11 Template Status

This figure shows setting the template status.