Job scheduler System Programming Interfaces (SPI)

Use SPIs to manage a list of groups to which a user is assigned, to control user actions against jobs, to suppress the writing of log lines, and to provide an installation-specific audit string validation rule.

SPI properties file

The SPI class can be added to $WAS_HOME/lib/classes or to the job scheduler shared library. Use the configCGSharedLib.py wsadmin script to assign the shared library to the job scheduler.

Table 1. Attributes of a property file . The table lists the property file and its attributes.
Property file	Attribute
Name	xd.spi.properties
Location	`app_server_root`/properties
Format	<`SPI name`>=<`SPI implementation class`>

Group membership filter SPI

Use the group membership filter system programming interface (SPI) to manage the list of groups to which a user is assigned. You can use the SPI in two ways:

To modify the list of groups that the federated repository returns
To serve as an alternative to the federated repository. In this case, the SPI is the source of user and group membership information that batch uses.

The SPI is called each time a user logs on to the job management console and each time a job operation is performed.

Table 2. SPI name . The following table lists the name of the SPI.
Name
group.membership.manager

Job log filter SPI

Use the job log filter SPI to suppress the writing of log lines to logs from batch applications. You can suppress writing the log lines to the server logs, job logs, or both types of logs. You can also override the application log line.

Implement the com.ibm.wsspi.batch.joblog.JobLogFilter interface by implementing the getName() method and the processJobLogLine() method. The getName() method is required for all SPI implementations. The processJobLogLine() method returns a JobLogAction object to suppress where the job log line is written. You can override the application log line with the JobLogFilterListener object. Call the JobLogFilterListener object with the updated or replaced log line and job ID that would be written to log files based on the provided JobLogAction object.

Table 3. SPI name . The following table lists the name of the SPI.
Name
spi.job.log.filter

Job log filter SPI example

package com.ibm.websphere.samples;
import com.ibm.websphere.grid.spi.SPI;
import com.ibm.wsspi.batch.joblog.JobLogFilter;
import com.ibm.wsspi.batch.joblog.JobLogFilterListener;
public class SampleJobLogFilter extends SPI implements JobLogFilter {
/**
* Input:
* jobid
* logline - line about to be logged
* JobLogFilterListener - call back to override logline
* Output:
* JobLogAction:
* SUPPRESS - do not log this line
* JOBLOGONLY - log only to job log (not server log)
* SERVERLOGONLY - log only to server log (not job log)
* JOBLOGSERVERLOG - log to both job log and server log
*(this is the default action)
*/
public JobLogAction processJobLogLine(
String jobid,
String logline,
JobLogFilterListener filterListener) {
filterListener.setLogLine(jobid, "MyCompanyName:" + logline);
return JobLogAction.JOBLOGONLY;
}
/**
* Required for all Batch SPI implementations
**/
public String getName() {
return SimpleCIJobLogFilter.class.getName();
}
}

The processJobLogLine() method returns a JobLogAction object to suppress the writing of application log lines to the system logs. The call to the JobLogFilterListener object causes the job log lines to be appended with a standard text.

Ensure that the servers load this job log filter SPI by including a reference to this implementation class in the app_server_root/properties/xd.spi.properties file:

spi.job.log.filter=com.ibm.websphere.ci.samples.SimpleCIJobLogFilter

Ensure that the implementation class is available to the server through a server level shared library.

Job operation authorization SPI

The job operation authorization SPI provides administrators with further control over user actions against jobs. You can exercise fine-grained access control over each user action by permitting or denying the operation.

Invoke the SPI only after you apply the configured job security policy. The SPI is invoked only if the user is authorized to perform the operation. The SPI can override the system when the system permits the operation. However, the SPI cannot override the system when the system denies the operation. Therefore, the JobOperationAuthorizer serves only to limit the range of operations a user is authorized to perform. The SPI is not able to increase the range operations a user is authorized to perform.

Table 4. SPI name . The following table lists the name of the SPI.
Name
job.operation.authorizer

Audit string validation SPI

You can use the audit string validation SPI to provide an installation-specific audit string validation rule. You can use the validation rule to enforce local auditing requirements and provide custom error messages to guide the user to a successful save.

When the audit string validator is configured and installed, it is driven each time a repository job is saved through any of the available interfaces, which include the job management console, the command-line interface, or an API.

The audit string validator is driven and passed the name of the repository job, the current user, the xJCL, the value of the audit string, and an AuditStringValidatorCallBack method. The audit string validator can then decide whether the audit string is valid or not. If the audit string is valid, the audit string validator returns true. If the audit string is not valid, the audit string validator returns false. If the audit string validator returns false, you can supply text for an error message through the AuditStringValidatorCallBack method.

Table 5. SPI name . The following table lists the name of the SPI.
Name
audit.string.validator