Job & Method

Job & Method

Defining success return codes and success status

The methods executed by jobs included in a job sequence must have a defined value

for the success_return_codes property or the success_status property or both. The

dm_run_dependent_jobs method, which invokes sequenced jobs, uses one or both of

those properties to determine whether an invoked job completed successfully.

The dm_run_dependent_jobs method compares the values in the success_return_codes

property and the success_status property to the values in the job’s a_last_return_code

and a_current_status. The value in a_last_return_code is compared to the value or

values in success_return_codes, and the value in a_current_status is compared to the

value in success_status.

If you set only success_return_codes, dm_run_dependent_jobs compares the value in

a_last_return_code to the value or values in success_return_codes, and any value in

a_current_status is ignored. If you set only success_status, dm_run_dependent_jobs

compares the value in a_current_status to the value in success_status and ignores

the value in a_last_return_code. If the values in the comparison operation match,

dm_run_dependent_jobs considers the invoked job to have completed successfully.

If both success_return_codes and success_status are set, then dm_run_dependent_jobs

compares each to its corresponding job property. If either comparison fails,

dm_run_dependent_jobs considers the invoked job to have failed. If both comparisons

succeed, then dm_run_dependent_jobs considers the invoked job to have succeeded.

Note: The agent exec process sets the job’s a_last_return_code property. The property

is set to the value returned by the job’s method. The job’s a_current_status property

must be set directly by the invoked method.

Introducing job sequences

A job sequence is a set of one or more jobs that are executed in a user-defined order. You

can put replication jobs and custom jobs of any user-defined type in a sequence. You

cannot put system-defined jobs, other than replication jobs, in a job sequence. The jobs

can reside in different repositories, but all must reside in 5.3 or later repositories.

Sequences are an effective way to handle replication jobs that might overlap in their

operations because they allow you to define the order in which the jobs must be run and

no job is run until all of its predecessors complete successfully.

For example, perhaps you have two replication jobs with the same source and target

repositories. To ensure that the two jobs do not try to load the replicas into the target

repository at the same time, you can put both in a job sequence and they are run one

after the other, in the order you define.

A job sequence can contain any number of jobs, and the jobs can reside in different

repositories. However, you cannot put a job that requires multiple invocations, such as a

manual transfer replication job, in a job sequence.

Execution of the job sequence is initiated by a controlling job that you define. The

controlling job executes the dm_run_dependent_jobs method, which is installed with

Content Server.

Job Performance considerations

Use of either the method server or the Java method server improves the performance of

method execution.

To execute a method, Content Server generates a new process to execute the method.

That process opens a new session with the repository, which in turn opens another

session with the RDBMS.

Use of the method server avoids the overhead of the additional repository session and

RDBMS session. The method server runs continuously, so no new process is created to

execute the method. The first time the method server executes a method, it opens a

repository session and an associated RDBMS session. Thereafter, the method server uses

connection pooling. Use of connection pooling removes the need to open new repository

and RDBMS sessions for subsequent method executions.

Use of the Java method server provides similar performance benefits.

Job Security considerations

Security is only a consideration when you are executing a method on the Java method

server. When executing on the Java method server, there are two security issues:

• Determining the origin of the generated HTTP_POST request generated by the

DO_METHOD.

• Logging in without passwords.

To resolve the first issue, the invoked servlet ensures that the generated request comes

from a machine that hosts a Content Server by checking the IP address of the sender

against a list of repositories. When the Java method server receives a request, it issues

a DFC getServerMap() call to obtain a list of all servers servicing the repository. From

that list, it determines whether the IP address of the machine that originated the request

is a Content Server host. If the sender’s IP address does not match the IP address of

a Content Server host, the request fails.

The second issue occurs because the Java method server runs as the Content Server

installation owner. Consequently, the servlet it invokes to execute DO_METHOD calls

also runs as the installation owner. A process running on the Content Server host

as installation owner can log into the repository as the installation owner without a

password. Consequently, a servlet or an invoked Java method can log into the repository

with superuser privileges without providing a password.

If you write a method that logs in a user in that manner, you may want to ensure that

the actual user who issues the DO_METHOD to invoke the method has the appropriate

privileges to execute the program as a superuser. To do this, send the current username

and a login ticket to the method in the arguments. The method can use this information

to log in and check the privileges of the user before connecting as the current operating

system user.