Skip to end of metadata
Go to start of metadata

This document comprehensively describes the procedure of running Java code using Oozie. Its targeted audience is all forms of users who will install, use and operate Oozie.

Java Action specification

The Java action will execute the public static void main(String[] args) method of the specified main Java class. The required Java class(es) should be packaged in the form of a JAR and placed within your workflow application's lib directory.

The directory structure looks like this:

  • wf-app-dir/workflow.xml
  • wf-app-dir/lib
  • wf-app-dir/lib/myJavaClasses.JAR

When executing a java application without oozie, one specifies the class having the main function (main-class), run-time JVM options and the arguments to be passed.

Now with Oozie, they are specified as inline tags in the workflow.xml file.

The java-opts element, if present, contains the command line parameters which are to be used to start the JVM that will execute the Java application. For multiple command line parameters, there may instead be a java-opt element for each.

The arg elements, if present, contains arguments for the main function. The value of each arg element is considered a single argument and they are passed to the main method in the same order.

Java applications are executed in the Hadoop cluster as map-reduce job with a single Mapper task. Hence the Java action has to be configured with the following properties in the form of XML tags:

  • <job-tracker>
  • <name-node>
  • <configuration> element is used to specify key/value properties for the map-reduce job. Some common properties include:
    • specifies the queue-name that the job will be submitted to since the Java application is run from within a Map-Reduce job. If not mentioned, the default queue default is assumed.

Prepare block

A java action can be configured to perform HDFS files/directories cleanup such as deleting an existing output directory (<delete>) or creating a new one (<mkdir>) before starting the Java application. This capability enables Oozie to retry a Java application in the situation of a transient or non-transient failure (This can be used to cleanup any temporary data which may have been created by the Java application in case of failure).

The prepare element, if present, indicates a list of paths to do file operations upon, before starting the Java application. This should be used exclusively for directory cleanup for the Java application to be executed.

Capture-output element

The capture-output element can be used to propagate values back into Oozie context, which can then be accessed via EL-functions. Thus, in a workflow application with multiple actions, the output of the Java action can be accessed by subsequent actions.

  • This needs to be written out as a Java properties format file specified via the property
  • A useful EL function for capturing action output data is
    • Map wf:actionData(String node)

This utility is only applicable to action nodes that produce output data on completion.

The output data is in a Java Properties format and via this EL function it is available as a Map.

From Oozie v3.3 onwards, more EL functions are available so your Java code can process this output in numerous formats (e.g. Properties, JSON etc.)

For more details, refer to the section on EL functions in the Workflow Functional Specification


The example below illustrates the use of <capture-output> element and the corresponding java main function definition.

  • In this example, we pass a the PASS_ME variable between the java action and the pig1 action.
  • The PASS_ME variable is given the value 123456 in the java-main action named java1.
  • The pig1 action subsequently reads the value of the PASS_ME variable and passes it to the PIG script.

Java Main Class

The main() method writes a Property file to the path specified in the '' ENVIRONMENT variable.

Launcher configuration properties

Oozie executes the Java action within a Launcher mapper on the compute node. Some commonly used <configuration> properties passed for the java action can be as follows:

  • <> similar to using the <java-opts> described before
  • Setting environment variables

Thus summarily, mapred properties are applied to the java-action map job by prefixing "oozie." to those property names.

Java Action Transition

The workflow job will wait until the java application completes its execution before continuing to the next action. To indicate an ok action transition, the main Java class must complete gracefully the main method invocation.

To indicate an error action transition, the main Java class must throw an exception.

e.g. If the main Java class calls System.exit(int n) where n is non-zero, this will make the java action to do an error transition regardless of the used exit code.

Non-zero system exit will be error whereas a System.exit(0) will lead to ok transition.

Debugging inside Java classes

  • If the Java class function has any System.out.print commands, their output is seen on the HDFS Jobtracker task log (accessible via Oozie web-console by clicking on the job in the list and then using the console URL for jobtracker to view the log for your specific task).
  • Alternately, if you know your job-id from CLI, you can look up your job's logs from the jobtracker webpage and then the 'map' task logs. The Oozie launcher has some very informative log statements such as job properties and exception traces in these task logs.
  • If you are performing incremental changes to your java classes and want to see the changes reflected, you need to update the JAR that is supposed to include your java class. In this case, the JAR is the one inside your workflow application's lib directory.

where a.b.c.myMainClass is the package structure you wish to maintain in the JAR.

Java System Properties

Within your Java Main class, you can query for the following system properties pertaining to your Oozie job.

  1. : Workflow ID
  2. : Action ID
  3. oozie.action.conf.xml : local path to the resolved action configuration
  4. : Action properties output as a Java Properties file (described more in Java Action Specification section. See the use-cases for illustration)

This provides for a convenient way to access these values directly within the action code.

Java action XML Schema

The XML schema definition for Oozie workflows specifies an 'xs:sequence' for the tags within each action block. Hence, for a valid workflow application, the various tags e.g. prepare, configuration, java-opts, arg, file, archive etc. should be given in the right order. Note that some of the tags are optional, but if used, the order should be kept in mind. For e.g. if using <file> or <archive> to copy some class files from known hdfs locations to your task cache, they should be specified after any <configuration> or <main-class> tags.

  1. job-tracker (required)
  2. name-node (required)
  3. prepare
  4. configuration
  5. main-class (required)
  6. java-opts
  7. arg
  8. file
  9. archive
  10. capture-output

Some tags are required. Rest all are optional.

For more information the XSD for Java action looks like the following:

Authenticating on a Kerberos-enabled cluster

In order for a Java action to succeed on a secure cluster, it must propagate the Hadoop delegation token like in the following code snippet (this is benign on non-secure clusters):

Examples and Use-Cases

Following are example workflow applications that illustrate use-cases of the Oozie Java action.

I Using Java-Main action to copy local file to HDFS

Assume a local file $filename can be accessed by all cluster nodes.

  • Define a java action in your workflow.xml
  • Here is a sample java main class.

II Java-Main Action decision nodes

This example is to illustrate how action output data captured using capture output can be used in decision nodes.

The corresponding Java class can be as below:


<to be compiled>

  • No labels