Siva's Blog

Creating ESS Job metadata using EM Console

Creating ESS Job metadata using JDeveloper

Creating ESS Schedule metadata

Creating ESS Incompatibility metadata

Creating ESS Job Sets metadata

Retry functionality in ESS Jobs

Creating Async ESS Job Definition

Using Schedule Job activity in BPEL

In the post, we have seen creating ESS Job Definition using synchronous web service. Now, we will look at creating Job Definition using  Asynchronous BPEL web service having 5 min Wait activity to simulate the delayed response.

We will also take a look at other changes required for deployment when new job definition is created in existing ESS application in new package structure.

Create Async Job Definition with help of following screenshots. Make sure that you always use the concrete WSDL.

You need to modify MAR profile to include the new job definition and also adf-config.xml file to include the valid namespace as shown below.

Now deploy ESS application and submit a new request using this job definition. You would observe that ESS job status is in Running state but waiting for the response from BPEL web service as shown below.

Once ESS job receives the response from asynchronous BPEL web service the job will be finished and shows status as Succeeded as shown below.

You will see the similar behavior as above even when you use ADF BC service.

Often, we may have to run multiple jobs to finish some functional process. ESS lets you do this using Job Set where we can add multiple jobs as steps in the metadata and submit them as single unit. We can also specify the relationship among these steps either as Serial or Parallel.

Job Set also allows another Job Set to be included so that a parallel job set can have a Serial Job set and vice versa so that more more complex Job Sets can be created.

To create Job Set, select File –> New –> Enterprise Scheduler Metadata –> Job Set.

Give a meaningful name and use the same package as used in previous post.

Click OK and you can observe new Job Set shown in Project Explorer and a new tab is opened.

Let us create Serial Job Set at first. Click + in the Job Set Steps option to add jobs. We can also specify any System Application properties at each step using the respective tabs shown below.

Now your Job Set Steps visual diagram look like below. After the execution, each job step can assume any of the statuses Success, Warning and Error represented by icons in below screenshot. Here, you can define relationship of steps with other steps based on the status. So the following diagram depicts that Job Set execution to stop on occurrence of Error or Warning and proceed to next step (if any) on Success.

Similarly add another step as shown below.

Now modify the relationships of Step1 as shown below.

Now save your changes and deploy to ESS server using the steps mentioned in previous post.

To view the newly created Job Set in EM console, navigate to ESSAPP –> Job Metadata–> Job Sets and do search for EssNativeHostingApp as shown below.

Navigate to ESSAPP –> Job Requests –> Submit Job Request and submit Job Set as shown below.

Run this Job Set when the service is down so that we can see it’s behavior when an error occurred during execution. Observe that both of the steps are resulted into an error as shown below.

And Search Job Requests page shows these requests as below where each step is executed as child request and we can also observe the serial execution by looking at Processing Start Time and Run Time.

Now modify Step1 to Stop on occurrence of error. Now save you changes and deploy your application to ESS server.

Submit request using this Job Set and observe the Job Status as shown below. Now you can clearly observe that only Step1 has been executed because of the above changes.

Now bring up service and submit the Job Set to observe both of the steps are successful.

By default, each step status does determine the terminal state of Job Set. To override this behavior you can define the system property SYS_selectState at step level as shown below and set value to false.

ss

In Parallel job set, all steps execution will start at same time hence we can’t define relationships among steps based on step execution status similar to Serial job set. However, you can still define the step level system parameter SYS_selectState to override default behavior.

Now save changes and deploy application to ESS server. Submit a request using this new Job Set and observe the parallel runtime behavior as shown below.

You can find more information about Job Sets in ESS documentation here and sample project used in this blog can be downloaded from here.

Using EM Console to Create Job Set

We can also create a Job Set in EM console as shown below and the steps look similar to above.

We often come across following restrictions when we use ESS jobs because of data corruption issue or for some other functional reason.

• Only single instance of Job definition should run at particular time.
• Some jobs should not be run during the run of other jobs irrespective of parameters.
• Some jobs should not be run during the run of other jobs when acting on same object i.e. having same value for a particular parameter.

In ESS, all of above requirements are addressed by using Incompatibility definition. The first requirement is addressed by using Self Incompatible option. Second and third requirements are addressed by using Global and Domain type incompatibility definitions. In this blog post, we will learn how to create Incompatibility catering to above requirements.

To create Incompatibility metadata, select File –> New –> Enterprise Scheduler Metadata –> Incompatibility.

Give a meaningful name and use the same package as used in previous post. Here we are creating Global type.

Click OK and you can observe the new Incompatibility file shown in the project explorer and a new tab is opened.

Click + icon in Entities section to start adding the jobs.

Select the required jobs and click OK. If we try to save , we will get an error as shown below. As shown below, aAn Incompatibility definition mandates us to select Self Incompatible option when we are adding just single job (entity).

To set this option, double click job in Entities section and choose the option as shown below and click OK. This would make ESS request processor run only single instance of this job at a particular time.

Now save your changes and deploy to ESS server using the steps mentioned in previous post.

To view newly created Incompatibility in EM console, navigate to ESSAPP –> Job Metadata–> Incompatibilities and do search for EssNativeHostingApp as shown below.

To verify the effect of incompatibility, let us submit 2 instances of the same job and schedule them to run at same time as shown below.

On the scheduled time, we can observe that one of the requests is blocked as shown below because of our incompatibility definition.

Once the job with request id 205 is completed, 206 will be kick started by request processor which is evident from the start times shown in the below screenshot.

If you want to make 2 job incompatible with each other, add the other job in the incompatibility definition as shown below.

Similar to above, you can observe the same blocked behavior for these 2 jobs in following screenshots when submitted in EM console at the same scheduled time.

Domain type Incompatibility

You can create incompatibility definition of Domain type using the following screenshots.

Double click on each job in Entities section to select the property to be used for defining the incompatibility. Note that, we can have different property names to define the incompatibility definition.

Now your incompatibility definition should look like below.

Now deploy your ESS project to verify effect of new incompatibility definition. Note that you have to remove SecondOSBJob from previous incompatibility definition before deployment as that is of Global type and is necessary to see effect of this domain type incompatibility which is based on properties.

When used different values for the parameters, you can observe that both jobs started execution at same time which is evident from the date values shown below.

When used same values for the parameters, you can observe that one of the requests is blocked which is evident from the following screenshots.

Using EM Console to Create Schedule

We can also create a Incompatibility in EM console as shown below  and the steps look similar to above.

You can find more information in the documentation here and sample project used in this blog can be downloaded from here.