Core functions

All the configuration of the importer must be made using system environment variables. For example, the importer expects there to be variables containing paths to local directories, URLs to Solr servers, to the email server, and so on. For this reason, there is a class that deals with reading the environment.

The necessary data to access the Git repository is also stored in environment variables. In the first step when the importer program is executed, the local Git repository is automatically updated. All the necessary information that needs to be shown to the user is delivered to the user interface.

When the user starts the importing process, several things come into motion. All the actions, warnings, and errors of the importing process are logged into a local file. In the end, the contents of this file are sent to the given email address. During the importing process, the dependency injection (DI) container is started. It is responsible for loading the actual importer steps which are then executed in sequence.

Here you can see a more detailed view of the DI container.

Classes that have been loaded into the DI container are called beans. Each bean contains one importer step. The references to actual classes and their execution order are defined in the beans configuration file. The Solr importer has a configuration file which is read by default, i. e. when there is no project-specific plugin available. The default file defines some basic importer steps:

• A waiting period of 10 seconds. This one has proven itself useful, because the user sometimes realizes having clicked the "import" button by mistake or too soon. With this step, the user has a chance to cancel the import process, before it really begins.
• Uploading files from a local folder to a Solr server.
• Swapping two cores in a Solr server. It is common to first upload the Solr files to one core that is not online. Only after a successful upload should this core go online. This way, you can make sure that your Solr server does not go offline for long time periods. Also, the fact that this is the last importer step means that the user can cancel the import process in any preceding step without affecting the current online core (and its index).

The DI container dynamically searches for the plugin and its own project-specific beans configuration file. If it is found, then it is used instead of the default file. This means that each project that reuses this Solr importer, can and should define its own importer steps. The ones from the default file can be reused by copy-and-pasting their bean definitions into the project-specific beans configuration file. New importer steps can be implemented and added to the configuration. For example, it is often necessary to transform some text or XML files to Solr-specific XML files, before they can be uploaded to Solr.