Oracle ATG Commerce comes with a tool called RLClient as part of the repository loader tools.
RLClient can be used to manipulate file based assets, such as slots, scenarios, and targeters. This can be useful for reloading assets, as well as moving them between environments - for example from production to QA.
The post is going to assume the BCC is being used to manage file based assets.
If you are creating your own slots, scenarios, and targeters; it is a good practice to store them under source control.
If you have not done this, here are steps to get them from an instance they have been deployed to.
Assets published with the BCC are pushed to a virtual file store in your target ATG instances.
This is typically located in your atg.server.home for a given instance. For example:
In the case of a standalone EAR deployment, this location will usually change to ATG-Data directory, which is often located in your Weblogic DOMAIN_HOME.
Once you have located the live virtual file system, you will find your deployed slots, scenarios and targeters. They are stored in sdl and properties files under this directory tree.
Save these files, preserving the directory structure under the live/config directory. For example, /atg/registry/data/scenarios/DCS/RelatedItemsSlot.sdl
Copy the assets you want RLClient to load to your $ATG_HOME directory. Assets should include the full component path.
For example, with my $ATG_HOME being /opt/atg/atg11.2/home, I would have the following files.
The entire component path (/atg/registry/....) is preserved.
The RLClient tools uses an XML structured file manifest the defines the assets you want it to load into a target environment.
Slots, Scenarios, Targeters, and folders these assets appear in are defined in the manifest.
The following is a sample manifest show each type of item:
<manifest> <!-- FileFolder Mappings --> <add type-mapping="/atg/epub/file/typemappers/FileFolderTypeMapping"> /opt/atg/atg11.2/home/atg/registry/data/scenarios/DSS </add> <!-- Scenarios --> <add type-mapping="/atg/epub/file/typemappers/ScenarioTypeMapping"> /opt/atg/atg11.2/home/atg/registry/data/scenarios/DSS/TrackActivity.sdl </add> <!-- Targeters --> <add type-mapping="/atg/epub/file/typemappers/TargeterTypeMapping"> /opt/atg/atg11.2/home/atg/registry/RepositoryTargeters/ProductCatalog/HomeTheme.properties </add> <!-- Slots --> <add type-mapping="/atg/epub/file/typemappers/SlotTypeMapping"> /opt/atg/atg11.2/home/atg/registry/Slots/HomeTheme.properties </add> </manifest>
This example assumes ATG is installed at /opt/atg/atg11.2, making my $ATG_HOME /opt/atg/atg11.2/home.
The rest of the path after $ATG_HOME is the full component path for each asset.
You fill this file manifest in with all the assets you want RLClient to load in the target environment.
Make sure you create directories with FileFolderTypeMapping for any assets not stored in the root folder, or you will get an error when trying to load them.
For this example, save the file manifest as fileManifest.xml.
In dyn/admin on the BCC instance you want to deploy your assets to, navigate to /atg/epub/file/VersionedLoaderEventListener/
Set createProcesses to true
You only need to do this to run the RL command. Do not persist this setting in a property file.
It will revert to the defaults when you restart the instance, or you can manually change it back to false after loading your assets.
Now execute the RLClient script, which is located in $ATG_ROOT/RL/bin.
Pass in the file manifest you create, the hostname of the target BCC instance, and the RMI port of the target BCC instance. Example:
/opt/atg/atg11.2/RL/bin/RLClient.sh -m fileManifest.xml -h localhost -r 8861
This will deploy all the assets in your fileManifest.xml to the BCC target you specified. You can manage and deploy these assets from the BCC now.
In this example, I executed RLClient.sh from the directory where my fileManifest.xml was located.
A real use case where this process is helpful is moving assets between environments.
If you have business users updating slots, scenarios and targeters in a production environment, and you want to periodically sync these back to your dev or QA environments, this process can be used instead of manually recreating these assets in your other environments.
The same idea would apply if you have developers creating assets in a development environment, and you want to move them to QA for testing, then to production after testing is complete. No need to manually recreate all the assets.