Creating your own Crontab plugin

You can create your own Antivirus Analyzer.

Conditions:

  • The new Antivirus Analyzer class must implement the "CronAdapter" interface.
  • The new Antivirus Analyzer class must be declared under the package "com.openkm.plugin.cron".
  • The new Antivirus Analyzer class must be annotated with "@PluginImplementation".
  • The new Antivirus Analyzer class must extend of "BaseCronPlugin".

Antivirus Analyzer interface:

package com.openkm.plugin.cron;

import net.xeoh.plugins.base.Plugin;

public interface CronAdapter extends Runnable, Plugin {
	/**
	 * The cron name
	 */
	String getName();

	/**
	 * The default cron expression what will be registered the first time
	 */
	String getCronExpression();

	/**
	 * Return if task is running or not
	 */
	boolean isRunning();

	/**
	 * Cron task execution
	 */
	void execute();
}

The new class must be loaded into the package com.openkm.plugin.cron because the application plugins system will try to load it from there.

Do not miss the tag @PluginImplementation otherwise, the application plugin system will not be able to retrieve the new class.

More information at Register a new plugin.

Method description

MethodTypeDescription

getName()

String

Return the name of the crontab.

getCronExpression

String

Return the cron expression.

isRunning

Boolean

Return true when cron task is running.

execute

Void

Execute the cron task.

Example of the disposition cron implementation

package com.openkm.plugin.cron;

import com.openkm.api.OKMRepository;
import com.openkm.bean.Folder;
import com.openkm.module.db.stuff.DbSessionManager;
import com.openkm.util.FileLogger;
import net.xeoh.plugins.base.annotations.PluginImplementation;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Autowired;


@PluginImplementation
public class TestCron extends BaseCronPlugin implements CronAdapter {
    private static Logger log = LoggerFactory.getLogger(TestCron.class);
    private static String LOG_NAME = "TestCron";

    @Autowired
    private OKMRepository okmRepository;

    @Override
    public String getName() {
        return "Cron test";
    }

    @Override
    public String getCronExpression() {
        return "0 * * * * *";
    }

    @Override
    public void execute() {
        try {
            FileLogger.info(LOG_NAME, ">>> Started");
            // Use always system token in your cron
            String token = DbSessionManager.getInstance().getSystemToken();
            Folder rootFolder = okmRepository.getRootFolder(token);
            FileLogger.info(LOG_NAME, "Root folder uuid: " + rootFolder.getUuid());
            FileLogger.info(LOG_NAME, ">>> Finished");
        } catch (Exception e) {
            log.error(e.getMessage());
        }
    }
}

Understanding the crontab job execution context

Execution context:

  • Crontab job is executed by internal users named "system" ( the job has not a valid user session ).
  • Crontab job is executed by the administrator user ( the job has a valid user session ).

All API methods have a variable named token.

When a user is logged the call to the API use token value to null. That indicates the application must use the logged session.

When a user is not logged, the call to the API must use a not null token, otherwise will get an error.

Example of use:

  • logged user -> valid API call -> OKMFolder.getInstance().createSimple(null, "/okm:root/test");
  • not logged user -> invalid API call -> OKMFolder.getInstance().createSimple(null, "/okm:root/test");

 Use the system token is a good practice when calling API methods into crontab task:

String systemToken = DbSessionManager.getInstance().getSystemsystemToken();
OKMFolder.getInstance().createSimple(systemToken, "/okm:root/test")