PluginDevelopment

• Batches
• Jobs
• Triggers
• Batch parameters
• Deployment

There are currently three types of plugins: Batches, Jobs (with Flows & Steps) and Triggers.

First off, there's a naming convention for all plugins: If you create a custom batch or trigger class, its name has to end with "Plugin"!

Batches

A batch is a subprogram that can be placed in a queue manually or by scheduler. It will be executed, when the batch is in the first position of the queue.

So your custom batch has to be named like "MyCustomBatchPlugin" and it also has to extend the following abstract class: de.gadiv.integration.server.batch.DefaultBatch

Any class that extends "DefaultBatch" has to implement the following methods:

• init(): Method to initialize the batch, when it's being processed in the queue. init() will be executed before the batch status is switched from "WAITING" to "RUNNING".
• execute(): Method in which the real work of the batch is done. It is called right after the batch status switched to "RUNNING". execute() should return a BatchStatus object: "FINISHED", if the batch was executed without errors, or some error status("FINISHED_WITH_WARNINGS", "TECHNICAL_ERROR" or "FUNCTIONAL_ERROR"). For more information, see the class de.gadiv.integration.server.batch.BatchStatus. The returned status will be the new status of the batch.
• finish(): Method to finish the batch. It is called after execute and after the new status is set.
• getVersion(): Returns the batch version as String.
• getName(): Returns the batch name as String.
• getDescription(): Returns the batch description as String.
• getParamNames(): Returns all names of parameters, that are needed to start the batch as a list of Strings. Below there's more information about the usage of parameters
• isRestartAllowed(): Returns TRUE or FALSE depending on your decision, if the batch should be restartable or not.
• isAbortAllowed(): Returns TRUE or FALSE depending on your decision, if the batch should be abortable or not.
• afterSubmit(): A method that is called, right after the batch is inserted into its queue (this can be a long time before it is actually started).

Jobs

Jobs are an extension to normal batches, because they support a more complex design of program flow and parallelization.

Your custom job has to be named like "MyCustomJobPlugin" and it also has to extend the following abstract class: de.gadiv.integration.server.batchx.DefaultJob
DefaultJob extends the class de.gadiv.integration.server.batch.DefaultBatch.

The job class contains a list of so called 'steps'. A step is an executable unit which can be defined by the batch developer. These steps will be executed during batch execution in the order of adding them to the batch. There are several types of steps:

• TaskStep: The most simple type of step. It has a run() method which should be implemented by the batch developer. run() is meant to contain the essential program logic of the step. There's also a rollback() method which can be overridden, for example if your batch relies database connections.
• ChunkStep: A chunk step is a more specialized type of step, for the purpose of processing large numbers of similar or equal operations. A chunk step generally reads data from a specific location (you have to implement an ItemReader for that), processes these items (ItemProcessor) and writes the results somewhere (ItemWriter).
• DefaultFlow: A flow is a special type of step that contains other steps or flows. A DefaultFlow processes all containing steps or flows sequentially.
• ParallelFlow: A ParallelFlow is similar to DefaultFlow but processes all containing steps or flows in parallel.

The steps / flows described above should be added to the job object by calling addStep(). They can be combined arbitrarily. A flow can contain more steps and flows, which can contain more steps and flows, etc.

There's also a so called JobContext which contains a serializable object 'contextData'. The contextData represents the progress of the batch. In case it was cancelled or crashed, the batch can extract information from this object to know where to continue with the execution.
If your batch should be able to continue at a certain point after failure, you have to implement the serializable object depending on the needs of your batch. And of course you have to evaluate the information of the contextData inside your batch / steps.

For an example how these classes work together see the following link.

Triggers

A trigger is a plugin that can be used to start certain actions, if a certain event happens. For example you could think of a trigger that copies files from one directory to another, if they appear in a certain folder or reach a certain size.

It's up to you to define (in the execute() method) what the trigger checks or observes and what it does, if a certain event happens.

Your custom trigger has to be named like "MyCustomTriggerPlugin" and it also has to extend the following abstract class: de.gadiv.integration.server.trigger.AbstractTrigger

Any class that extends "AbstractTrigger" has to implement the following methods:

• execute(): Method in which the trigger can check or observe whatever it needs to do, depending on its purpose. This method is called every few seconds by a seperate thread (you don't have to worry about that - it's built in giServer core).
• getVersion(): Returns the trigger version as String.
• getName(): Returns the trigger name as String.
• getDescription(): Returns the trigger description as String.
• getParamNames(): Returns all names of parameters, that are needed to start the trigger as a list of Strings. Below there's more information about the usage of parameters

Batch parameters

Parameters are a way to make your plugin configurable. You can pass parameters to your batch in the giServerManager GUI when starting a new batch or when creating a new scheduler or trigger. There's a text area, where you can insert your parameters like this (one per row):
MY_PARAM_1=some text
MY_PARAM_2=12345
...

If you want to read this params in your batch or trigger dynamically (for example the init() method of a batch would be a good spot for that), you can call getParamString(MY_PARAM_1), which would return "some text" or getParamInteger(MY_PARAM_2), which would return 12345.

Deployment

When you're done with coding, you have to place the JAR-files containing your compiled code in the "ext" folder of your giServer. At giServer start, it will check this folder and find any plugins it can use (Class name ends with "Plugin" and extends "DefaultBatch" or "AbstractTrigger"). If everything went right, you can start a new batch with your batch class or define a trigger using your trigger class.