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 "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 plugin system will try to load it from there.

Do not forget 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

Returns the name of the crontab.

getCronExpression

String

Returns the cron expression.

isRunning

Boolean

Returns true when the cron task is running.

execute

Void

Executes the cron task.

Example of a 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:

  • The crontab job is executed by internal users named "system" ( the job does not have a valid user session ).
  • The 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 in, the call to the API uses a null token value. That indicates the application must use the logged session.

When a user is not logged in, the call to the API must use a non-null token; otherwise an error will occur.

Example of use:

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

 Using the system token is good practice when calling API methods in a crontab task:

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