| Oracle® Retail Predictive Application Server Cloud Edition Administration Guide Release 19.0 F25569-31 |
|
 Previous |
 Next |
| Oracle® Retail Predictive Application Server Cloud Edition Administration Guide Release 19.0 F25569-31 |
|
Previous |
Next |
This chapter addresses the following batch administration tasks:
The application-specific batch tasks are a set of tasks that help the Administrator to load/export a predefined set of data and hierarchies. These tasks are found in the Online Administration Tools as Configured Batch Tasks.
Each task in turn calls predefined batch services to do the required tasks. For example, MFP Cloud Service uses the Enterprise Edition batch framework to define the batch process.
Some tasks require input data files or hierarchy files as input. These files must be uploaded before the tasks are scheduled. Some tasks export files out of the application. Those files are copied to the SFTP export location, and Administrators can download these exported files.
The SFTP file location is a space provided to the Administrator to load import files and access exported batch files. For more information, see "Uploading and Downloading Batch Files."
The following table shows the list of application-specific administration tasks that are pre-configured for MFP Cloud Service:
| Configured Batch Tasks |
|---|
| Run Batch Measure Load Group |
| Run Batch Measure Export Group |
| Run Batch Calc Group |
| Run Batch Task Group |
| Clean up Task |
| Upload Batch Control Files |
| Retrieve Batch Control File |
| Manage JSON Files |
| Patch JSE Jars |
| Remove JSE Jar |
| Translation Tasks |
|
Note: These are OAT tasks only and will work only if the batch control files are loaded to the domain. Refer to the Oracle Retail Merchandise Financial Planning Cloud Service Implementation Guide and Oracle Retail Merchandise Financial Planning Cloud Service Administration Guide for sample control files. |
This task is used to load a predefined set of measures grouped as a measure set in the batch control file batch_loadmeas_list.txt. These set of measures can be loaded together. All required data files must be uploaded to the SFTP location before scheduling this task. For more information, see "Uploading and Downloading Batch Files." If there is no file present to load a particular measure in that measure set, it will be logged as not found and skipped.
This process will only load the data into those measures and will not run any subsequent calculations. The Administrator may need to schedule the necessary Run Batch Calc Group task after scheduling this task in order to process the loaded data.
For details about the list of measure files that are loaded for different measure sets and information on the data file formats, see the Oracle Retail Merchandise Financial Planning Cloud Service Implementation Guide.
With Enterprise Edition implementations, the Run Batch Measure Load Group task can be customized to load different sets of measures by making changes to the batch control files. For information about changing the batch control files and how to upload them, see the Oracle Retail Merchandise Financial Planning Cloud Service Implementation Guide.
This task exports a predefined set of measure data into flat files. The predefined set of measures to be exported are defined in the batch control file batch_exportmeas_list.txt. This set of exported data can be used for integration with other applications. Typically, the data is exported to a database that creates a report or allows a query by users. The Administrator needs to schedule the Set Export Flags under the Run Batch Calc Group task to set the required export flags before scheduling this task. Exported files for this task are put into the SFTP Export location; the Administrator can download the files from this location. For more information, see "Uploading and Downloading Batch Files."
With Enterprise Edition implementations, the Run Batch Measure Export Group task can be customized to export new versions of data or remove a particular version of the list of measures exported by changes to the batch control files. For information about changing the batch control files and how to upload them, see the Oracle Retail Merchandise Financial Planning Cloud Service Implementation Guide.
This task is used to run a predefined set of all batch rules (as batch calc sets) against the domain to do the necessary data aggregation that is defined in the batch control file batch_calc_list.txt.
With Enterprise Edition implementations, the Run Batch Calc group task can be customized to change the batch calculations and the order in which they run against the domain by changing the batch control files. For information about changing the batch control files and how to upload them, see the Oracle Retail Merchandise Financial Planning Cloud Service Implementation Guide.
This task is used to schedule a predefined set of batch tasks such as load measure, batch calc, and batch exports in a sequential order. The batch control file batch_exec_list.txt defines the steps in the specific order that will be executed during batch task execution. This task is used to schedule a typical daily or weekly MFP Cloud Service batch. If any task aborts, a log is created and the process terminates. This task has the option to restart from the last failed service rather than running all the completed services again.
|
Note: Typically, the user must schedule this task within a time frame after a domain backup and when no users are logged into the domain. The Administrator must work with Oracle to find out the time of backups and any other jobs. |
With Enterprise Edition implementations, the Run Batch Task Group task can be customized by making changes to the batch_exec_list.txt control file. For more details about the list of internal services this task can call and how to change the order of services to this task, see the Oracle Retail Merchandise Financial Planning Cloud Service Implementation Guide.
This task is provided to clean up the processed files or unprocessed files from different cloud service locations to be run by the retailer on an as-needed basis. The user can choose Delete all files in order to clean up all the selected folders or can clean up the files under the selected folders that are older than specific days by choosing the option Delete files older than selected days and selecting the number of days from the drop-down list. The user can delete files older than days ranging from 0 to 99, where'0' is the current day.
This task has the following four options, used to select the locations to clean up when this task is scheduled:
Clean Incoming FTP Holding Area - When incoming files are sent to the FTP site, a process then moves those files to an internal holding area from which the batch framework can process them. In cases where files are sent using FTP and then not used by any batch process (for example, if the batch configuration has changed or if a file was misnamed), it becomes stranded in the internal holding area. This option is provided to remove all files from the internal holding area. Note that all files currently in the internal holding area will be removed, so this option must not be used when any scheduled batch processes are executing.
Clean Outgoing FTP Export Area - Select this option to remove all files from the outgoing FTP holding area.
Clean domain input folders
Clean processed folders - All processed input files are archived within the domain/input/processed folders. This option can be used to remove all the processed directories within a domain to reduce the growing domain size.
This task allows the currently configured batch control files to be retrieved if they must be inspected or modified. The files from the batch_control_cust directory are packaged together as the archive file batch_control_cust.tar.gz, and placed into the FTP area for retrieval.The files from the batch_control directory are packaged together as the archive file batch_control.tar.gz, and placed into the FTP area for retrieval. No parameters are required for this OAT task.
This task allows the configured batch control files to be uploaded in case they must be modified. The batch control files must be uploaded to the batch_control folder in the incoming FTP area. It is also possible to upload the control files as an archive. The archive filename must be one of the following: batch_control.tar.gz, batch_control.zip, [Application Name]_batch_control.tar.gz, or [Application Name]_batch_control.zip. The archive file must also be uploaded to the batch_control folder in the incoming FTP area. Make sure to upload only one archive file at a time. If multiple archive files are uploaded at the same time, only one will be used. If a control file is uploaded individually and also inside an archive at the same time, the one inside the archive will overwrite the individual one. No parameters are required for this OAT task.
This task can be used to upload or retrieve DashboardSettings.json and HelpConfig.json to the domain/fusionClient or to download the existing version of these two files that are currently in the domain/fusionClient. Note that these file names are prefixed with the application name.
To update them, the JSON files must be uploaded to the FTP area under the config directory in one tar.gz package with name as [Application Name]_json.tar.gz, or in one zip package with name as [Application Name]_json.zip. For retrieving the current files from the server for inspection or modification, the set of files are packaged together as an archive file with the name [Application_Name]_json.tar.gz, and placed into the FTP area for retrieval. No parameters are required for either of the options for this OAT task.
Retrieve JSON files to FTP
This option copies <appName>DashboardSettings.json and <appName>HelpConfig.json files currently in use in the domain/fusionClient folder to the outgoing FTP location. This task fails if both DashboardSettings.json and HelpConfig.json do not exist.
Update JSON files from FTP
This option copies <appName>DashboardSettings.json and <appName>HelpConfig.json files from the incoming FTP site and copies them to the UI installation location.
This task can be used to upload Java special expression jar files that are already registered with the RPASCE domain. It looks at the list of JSE jar files that are registered with the domain. For each jar file in the list, this task looks for the jar file in the jse folder under the incoming FTP location. Any such jars are moved to the domain's jse folder that will be used by the RPASCE solution. This task only has the task label and does not take any additional options.
This task removes and unregisters a Java special expression jar file from the domain.
JSE Jar file to be unregistered and removed. Enter the name of the jar file that must be removed.
|
Note: The files DashboardSettings.json or HelpConfig.json must be prefixed with the <appName>. If either file is incorrectly named, the task will skip over that file. If neither file has the expected name format, the task will fail. |
The RPASCE platform and its applications update the default translations in the domain as part of the regular upgrade and patch process. If the customer has existing custom translations, such as message strings or measure labels, for any of the default RPASCE strings, these translations may be wiped out after a patch or upgrade. To ensure that the custom translations are maintained after patches and upgrades, use the Translations task to upload custom translations. This task provides an upload option that manages the custom translations for both the server and the UI. This task includes other subtasks related to translation.
Use this task to upload and apply custom translations. The translations archive file name does not have any special restrictions but must have a .zip or .tar.gz extension. The translations files in it must be either without a top-level folder or with one folder containing all the files. If there is a top-level folder, the name of the archive must match the folder name. The task looks for input translation archives in the translations folder under the incoming FTP location.
The second page of the upload task provides a drop-down list of all available translation archives. The user can select one and continue. The translation dat files are loaded into the domain using loadHier; the translation measures files are loaded using loadmeasure. The UI translation files are also copied to the correct location. In addition, a copy of all the uploaded translation files are maintained internally. This helps to list and download just the custom translations.
Here is an example for the translation archive file.
$ tar -tzf tr.tar.gz tr/ tr/MultiSolutionBundle_de.properties tr/MultiSolutionBundle.properties tr/MultiSolutionBundle_es.properties tr/r_langattr.csv.ovr tr/MultiSolutionBundle_it.properties tr/r_measdescripti.csv.ovr tr/MultiSolutionBundle_en_US.properties tr/MultiSolutionBundle_pt.properties tr/r_measlabel.csv.ovr tr/MultiSolutionBundle_ja.properties tr/MultiSolutionBundle_en_AU.properties tr/MultiSolutionBundle_fr.properties tr/r_dimlabel.csv.ovr tr/r_grplabel.csv.ovr tr/r_msglabel.csv.ovr tr/msgs.csv.dat tr/lngs.csv.dat tr/MultiSolutionBundle_en_GB.properties tr/r_hierlabel.csv.ovr tr/MultiSolutionBundle_en_CA.properties tr/r_wbtglabel.csv.ovr tr/r_wbtlabel.csv.ovr tr/MultiSolutionBundle_nl.properties tr/r_measpicklist.csv.ovr
For the hierarchy and measure input files present in the translation archive, only modified records must be present. For example, if you change only the dimension labels listed below but the remainder of the dimension labels are default ones, then you must keep only the ones you have changed in the r_dimlabel.csv.ovr measure data file. This ensures that changes to the other dimension labels during patch will not be reverted to the old strings.
hier,english,Custom Hierarchy meas,english,Custom Measure rgrp,english,Custom Rule Group lang,english,Custom Language wb,english,Custom Workbook
If you do not edit the translation input files directly, but instead use the translation admin workbook to add the custom translations, then you must do the following. Use exportHier and exportmeasure to export the translation hiers and measures; diff against the default translation files present in $RPAS_HOME/domain/ml_input to find only the custom translations.
Similarly, for client side translation files such as MultiSolutionBundle_nl.properties, keep only the changed lines in the file. They will be merged with the default translations.
This task has the following options:
Remove server translations. Remove the custom server translations and load the default server translations back into the domain using loadHier and loadmeasure.
Remove UI translations. Remove the custom UI translations and load the default UI translations back. Changes will take effect once the UI is restarted.
Remove server and UI translations. Remove the custom server and UI translations. Load the default server translations back into the domain using loadHier and loadmeasure. Load the default UI translations back. Changes will take effect once the UI is restarted.
The next page of the Remove task provides a check box Delete the uploaded translations. If this is not checked, the custom server and UI translation files will continue to exist in the internal storage location and will not be deleted. They can be re-applied using the Apply Custom Translation task from the other translations tasks drop-down list. If this option is checked, the custom translations must be uploaded again.
This task consists of the following subtasks.
Apply Custom Translation
If translation files have previously been uploaded using the Upload Custom Translations task, it must now be applied to the domain using this task. However, the Upload task also applies the translations, and the patch scripts automatically call the Apply task during the domain patch process. Therefore, in a regular upgrade and patch scenario, the manual execution of this task is not required. However, this option is exposed through OAT to be used if required. For example, if the Remove Custom Translations task is executed without the Delete Uploaded Translation option, the Apply task can be run in order to re-apply the previously uploaded custom translations.
Download All Translations
This task exports all the translations that are currently in use by the server and UI. This includes both custom translations and the remaining default translations. The resulting archive file is placed in the outgoing FTP location. The name of the file is in the format Translations_<timestamp>.tar.gz.
Download Custom Translations
This task exports only the custom translations that are currently in use by the server and UI. The resulting archive file is placed in the outgoing FTP location. The name of the file is in the format CustomTranslations_<timestamp>.tar.gz.
List Custom Translations
This task lists the custom translations that are currently in use by the server and UI. To view the output of this task, examine the task log in the OAT dashboard.
The OAT task Download Application Domain Config option is available in Configured Batch Tasks, as shown in Figure 12-2.
This task is used to download the configuration of the domain. It does not require any task-specific settings or arguments. The task can be monitored through the Administration Dashboard. Upon successful completion of the task, the application domain configuration can be found in the Outgoing FTP location.
This task is used to create custom Retail Home content for EE solutions. GA RPASCE solutions provide a default configuration for Retail Home content. However, EE solutions will often require custom configuration to support that solution's content in Retail Home.
This task consists of the following two steps:
Create a Retail Home configuration to define what content must be displayed within Retail Home.
Upload the Retail Home configuration and apply its content to the Retail Home system.
The process of creating the Retail Home configuration is similar to the creation of the RPASCE Dashboard configuration. The task is performed within the Configuration Tools and results in the creation of two files: RetailHomeConfig.json, which contains the configuration settings, and RHResources.properties, which contains the keys required to localize the strings displayed in the Retail Home content for the solution.
For information on the process of creating a Retail Home configuration file using the Configuration Tools, see the "Deployment Tool - Retail Home Dashboard Settings" and "Retail Home Translation Resources" sections in Chapter 11 of the Oracle Retail Predictive Application Server Cloud Edition Configuration Tools User Guide.
The process of applying custom Retail Home content is performed from the Admin Tasks of the application.
The process for updating Retail Home with configured content consists of the following two steps:
Upload both the RetailHomeConfig.json and the RHResources.properties file through the FTP server.
Run Retail Home Seeding as shown in Figure 12-3 and Figure 12-4. This task does not require any arguments. A message indicating success or failure will be returned upon completion of task.
Upon successful completion of the task, subsequent logins to Retail Home will display the updated content provided in the configuration.
