Mirror of Oracle documentation
Converted for search and offline reading. Authoritative source: Oracle. Diagrams and some complex tables are simplified — check the PDF when in doubt.
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
-
Service Config JSON file serviceConfig.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.
Modular Configuration
MFPCS also supports the modular Solution Designer configuration for MFP. It will be treated as a nontemplate configuration and the build/patch process remains the same for both modular and non-modular configuration. The customer needs to generate the configuration for the selected modules and custom modules and upload the generated configuration for build/patch using the same existing process. If SD config was used during build/patch, standard workflow manager tasks configured for MFPCS will be available to the user under the Workflow Manager. The customer can copy the required taskflows or create their own taskflows and then publish the same in order to use the same in the application.
See the Oracle Retail Merchandise Financial Planning Cloud Service Starter Kit Guide to get the solution designer MFP GA modules and also its related batch control and interface.cfg files. See the Oracle Retail Predictive Application Server Cloud Edition User Guide Workflow Manager section for more details about the configuration of Workflow Flows.
See the Oracle Retail Predictive Application Server Cloud Edition Solution Designer User Guide for more details about how to configure new custom modules.
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.