Announcement: You can find the guides for Commerce 7.5 and later on the new Elastic Path Documentation site. This Developer Center contains the guides for Commerce 6.13.0 through 7.4.1.Visit new site

This version of Elastic Path Commerce is no longer supported or maintained. To upgrade to the latest version, contact your Elastic Path representative.

Data Population Tool Configuration

Data Population Tool Configuration

Command Line Configuration

You must be able to pass the environment-specific information, which might or might not be managed by the development team, and data to be processed to the CLI tool . Data and environmental information must be passed in separately, not in a bundle, with the tool so that third party can provide the information if required.

Spring Shell doesn't support passing in command line options to the tool, but only individual commands. Data Population CLI tool supports passing command to the tool using the Spring Shell unmodified to provide the functionality for processing commands.

Global Configuration Options

Global configuration options are the options that are provided as the first arguments before any command and its options are provided. These options cannot be provided after commands, because the options are treated as command options not global configuration options. Command options can be provided after any global configuration option, or if not the CLI shell is displayed and commands can be run interactively. You must provide the global configuration options in the following format:

./ [--myGlobalConfigurationOptionName
          [and any values]] { 0 or more } [myCommand [--myCommandOption [and any values]] { 0 or more, each new command separated by a semi-colon }
Annotation-Driven Global Configuration

With a DpCliComponent annotation to the classes, global configuration options can be implemented without implementing the CommandMarker interface to contribute commands. The global configurations options are contributed by annotated methods with the DpCliOption annotation.

If the class containing a DpCliOption annotated method is not annotated with the DpCliComponent annotation, the Data Population CLI tool cannot find the class.

Valid Global Configuration Option Method Signatures

The DpCliOption annotated methods must be defined to take 0 or 1 as input. For 1 argument, the argument must either be a String or a String[]. For global configuration option to take a single command-line value, the method must be declared to take a String. For multiple command-line values, then the method must a String[] would declared.

If the global configuration option is a flag option, the method is defined to take 0 arguments.

Pre-Processing and Post-Processing of Global Configuration Options

Methods can be annotated with BeforeAllGlobalCliOptions or AfterAllGlobalCliOptions annotations. These methods are invoked before or after all DpCliOption annotated methods. Optionally, these methods can also be annotated with the Order annotation to be ordered in execution. If processing needs to be ordered, the value should be saved by the DpCliOption annotated method, and that processing must be deferred to an ordered AfterAllGlobalCliOption-annotated method.For more information, see DataPopulationCliGlobalConfigurer for the class that processes the global configuration options and its life cycle methods.

Contributing Global Configuration Methods

The global configuration methods are loaded separately before control is passed to Spring Shell so that the tool can pre-process any global configuration options on the command line and then pass the remaining command line options, if any, to Spring Shell. To contribute global configuration methods, including life cycle methods, the DpCliComponent annotated classes need to be declared in an XML Spring bean definition file using the following path:


Passing Control to Spring Shell

Spring Shell creates its own Spring application context as a part of initialization, and it does not allow an existing application context to be passed to it. with Spring Shell, these Strings can be passed indirectly to the Spring Shell application context through system Properties. Elastic Path does not recommend this method, however it is a better approach in general to using static fields as it reduces the coupling between systems to just shared System Property values. Hence, the existing global configuration methods validate input and then set any values required to be passed to the Spring Shell application context as System Properties. The property values are then injected into the appropriate beans in the Spring Shell application context via property placeholders. This avoids another smell of directly reading these values in the code from System Properties rather than allowing the values to be injected.