Archive Page 4

Creating Ubuntu VM in Oracle Virtual Box

In this post, will describe steps required to install Ubuntu64 virtual machine in Oracle VM Virtual Box. Most of the people may be aware of it so here I am just listing down the required steps.

Note that, here I am using Oracle VM Virtual Box 4.3.24 and installing Ubuntu 14.04.3 (64-bit) VM for demonstration.

  • Open Oracle VM VirtualBox and select File –> New.
  • Give name as  Ubuntu64 or any meaningful name and select type as Linux and version as Ubuntu (64 bit).
  • Click Next and use  slider to select required RAM. We may want to select 1GB for better performance with min of 512 MB.
  • Click Next. Choose the option Create a virtual hard drive now and click Create.
  • Select hard drive type as VDI and click Next.
  • Select Fixed or Dynamic option based on requirements and click Next.
  • Give file name for virtual hard drive file and Click Create. Here you have the option to choose the required hard drive size. This will create new VM and will be shown in the Virtual Box Manager. Note that VM is not yet configured to use Ubuntu OS.
  • To configure, start VM by selecting Machine –> Start and select startup disk file ubuntu-14.04.3-desktop-amd64.iso which we can download it from Ubuntu website.
  • After selecting iso image click Start to initiate the Ubuntu OS creation.
  • Select the language and click  Install Ubuntu.
  • Check Download updates while installing and click Continue.
  • Choose the default option Erase disk and install Ubuntu and click Install now. Click Continue if you see any warning related to formatting disk.
  • Select your location and click Continue.
  • Select keyboard layout and click Continue.
  • Provide details for Name, Computer’s Name and enter the required credentials for VM. and click Continue.
  • Select Log in automatically if you do not want to enter a password each time you log in or select Require my password to log in.  Click Continue.
  • It will take a while for the installation of Ubuntu OS. Once that’s done, click Restart now for the changes to be effective.

We can use any of these commands file /sbin/init or uname –i to make sure that 64-bit OS has been installed.

We can find the OS version using command lsb_release –a.

If you observe that VM is not shown in the full screen mode, then we have to install Virtual Box Guest Additions using steps mentioned below and use the admin password wherever it asks during installation.

guestadd

guestadd1

guestadd2

Now restart the VM and now you would see the VM in full screen mode.

To access internet, make sure that you have following settings for adapter:

settings

nat

If you are behind proxy, you can set proxy by going to System Settings –> Network –> Network Proxy as shown below. Click Apply System Wide and give admin credentials if you are asked for authentication.

proxy

From command prompt, you can set using the following command:

                   export http_proxy=>:”>http://<<host>>:<<port>>

Doing SSH into VM from Host:

  • First install SSH server using the command sudo apt-get install openssh-server.
  • Setup a port forwarding in your VM settings as below and restart the VM. Navigate to VM->Settings->Network->Adapter 1-> Advanced->Port Forwarding.

  • We can connect to this VM using winscp as shown below.

SOA 12c – Maven Articles

Using Maven Sync Plugin

Using Maven for SOA Deployment

Using Maven for Service Bus Deployment

SOA 12c – Using Schedule Job activity in BPEL

In this post, we will learn how to use the Schedule Job activity to submit a ESS request from BPEL process during orchestration. And we will use the ESS job created from this post.

Create a Sync BPEL process and drag Schedule Job activity into BPEL from Components –> Oracle Extensions as shown below.

jobactivity

jobactinbpel

We need to create a MDS connection so that we can do the lookup for the ESS jobs. Create a new SOA-MDS Connection in Resources –> IDE Connections and select MDS partition essUserMetadata as shown below.

mdsconn

Double click on Schedule Job activity in BPEL to being up the below editor and select the required ESS job as shown in following screenshots. This way, we can also explore ESS jobs deployed to partition using different namespaces.

selectjob

selectjob2

selectedjob

Similarly, we can select Schedule if required as shown below.

selectsch

Navigate to Application Properties tab and give the value for Job Propetires using XPath expression as shown below.

jobargs1

jobargs2

jobargs3

We can also verify the ESS Job system properties in System Properties tab.

sysprop

Click OK to observe a sequence of activities are created in your BPEL flow as shown below. We can click each of these activities and observe what has been done automatically for us.

essexpand

essservice

On selecting the job, we will see following artifacts get created automatically in our project.

esswsdl

Since our composite using ESS abstract WSDL it will result into build errors. So modify your ESS partner link entry in composite.xml to add bindings and port as highlighted below.

<reference name="EssService"
           ui:wsdlLocation="WSDLs/ESSWebServiceAbstract.wsdl">
  <interface.wsdl interface="
http://xmlns.oracle.com/scheduler#wsdl.interface(ESSWebService)"
                  callbackInterface="http://xmlns.oracle.com/scheduler#wsdl.interface(ESSWebServiceCallback)"/>
  <binding.ws port="
http://xmlns.oracle.com/scheduler#wsdl.endpoint(ESSWebService/SchedulerServiceImplPort)"
        location="WSDLs/ESSWebServiceAbstract.wsdl"/>
  <callback>
    <binding.ws port="
http://xmlns.oracle.com/scheduler#wsdl.endpoint(ESSWebServiceCallback/ESSWebServiceCallback_pt)"/>
  </callback>
</reference>

Or generate configuration plan for composite and give port and binding along with ESS Webservice location as shown below.

<reference name="EssService">
      <binding type="ws">
        <attribute name="port">
          <replace>
http://xmlns.oracle.com/scheduler#wsdl.endpoint(ESSWebService/SchedulerServiceImplPort)</replace>
        </attribute>
        <attribute name="location">
          <replace>
http://localhost:7015/ess/esswebservice?wsdl</replace>
        </attribute>
      </binding>
      <callback>
        <binding type="ws">
          <attribute name="port">
            <replace>
http://xmlns.oracle.com/scheduler#wsdl.endpoint(ESSWebServiceCallback/ESSWebServiceCallback_pt)</replace>
          </attribute>
        </binding>
      </callback>
    </reference>

We can always verify ESS Webservice WSDLs by navigating to Webservices section in url >:>/ess">http://<<host>>:<<port>>/ess.

Deploy your SOA project using above configuration plan and Test.  Now we will observe the following error as ESS Webservices can’t be run with anonymous user credentials. To get away with that, modify the ESS webservice by attaching OWSM policy as detailed by Lucas in his blog.

svcerror

Since ESS Webservice is secured we need to attach the corresponding client policy to our Partner link and need to pass on the credentials of valid user. So as a first step, create a credential store key ESS_KEY_USER with weblogic credentials using the following steps in EM Console.

security

credkey

credkey1

Now attach the corresponding client policy to our partner link as shown below.

owsm4req

attchedowsm

Click pencil icon and modify OWSM policy to specify csf-key as shown below.

csfkey

This would populate wsm-assembly.xml file with the policy details as below.

owsmpolicy

Now again deploy the SOA composite and run. This time composite run will be successful and can observe the Request ID of ESS job as the response.

flowtrace

Navigate to ESSAPP –> Search Job Requests to see our job is submitted as expected and shows user as weblogic which is used in csf-key.

jobrequest

You can find sample project here.

Observation:

There is some run time error coming during BPEL process testing when we specified job description for Schedule Job activity as above. This is due to the missing quotes around so we have to manually open assign activity and surround your job description in quotes as shown below.

essissue

SOA 12c – ESS Articles

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

SOA 12c – Creating ESS Async Job Definition

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.

asyncbpeljob

projexplore

tab

selectwsdl

selectwsdl1

asyncws

asyncws1

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.

marchanges

adfconfig

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.

waitjob

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

aftersuccess

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

SOA 12c–Retrying ESS Job Request

ESS provides the retry functionality through System Parameter SYS_retries and retry happens when a system error occurs during processing of ESS job request. By default, the value is 0 which means no retries will be performed.

We can set the value or override this property while submitting the request as shown below or can add this parameter at design time in JDeveloper.

retry

Click OK and you can observe this in Parameters section as shown below.

param

You can observe the number of retries performed in Request Search page by navigating to ESSAPP –> Job Requests –> Search Job Requests as shown below.

retry1

SOA 12c–Creating ESS Job Set metadata

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.

jobsetnew

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

jobsetnew1

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

explrjobset

jobsetsteps

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.

step1

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.

step1graphic

Similarly add another step as shown below.

step2

step2graphic

Now modify the relationships of Step1 as shown below.

step1and2

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.

emjobsetview

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

submitjobset

submitjobset1

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.

jobsetstatus

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.

jobstatus1

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

step1stop

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.

step1stop1

step1stop2

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

stepsuccess

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.

sysprop1

sysprop2

ss

parallel1

parallel2

parallel3

parallel1step1

parallel1step2

parallel4

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.

jobsetparallel

parallestatus

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.

emjobset

emcreate1

emcreate2

emcreatestep

emcreate3

SOA 12c–Creating ESS Incompatibility metadata

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.

incomp

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

incompdef

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

projexpl

incomptab

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

joblist

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).

error

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.

selfincomp

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.

deployedincomp

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.

submitted

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

blocked

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.

starttime

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

secondjob

secondjob1

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.

schedule2jobs

sucess2jobs

Domain type Incompatibility

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

domainincomp

domainincomp1

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.

1stjobprop

2ndprop

Now your incompatibility definition should look like below.

2ndincomp

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.

sametime

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

samevalues

samevalues1

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.

emincomp

emincompcreate

createincomp

entitylist

selfincompem

defn

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

SOA 12c–Creating ESS Schedule metadata

The real strength of ESS comes from the ability of scheduling a job which is a common use case. ESS provides Schedule as the job metadata to enable the user to schedule job either based on recurrence or on explicit dates. In this post, we will see how to create this Schedule metadata and use it for our ESS job created in the previous post.

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

newsch1

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

newsch2

Click OK and you can observe the new schedule in project explorer.

schprojexplore

Let us define a schedule so that ESS job runs for every 2 min thrice considering Start and End dates as shown below. You can also give explicit dates to be included regardless of recurring settings in the respective section. Observe that we are not specifying any ESS job while defining the schedule which enables the reuse of schedule and can be used for any ESS jobs.

newsch3

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

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

emnewsch3

You can also set the recurrence settings using Every field for seconds, Hours, Days, Weeks etc.. as shown below.

recurr

And appropriate selection of days, weeks etc.. will be enabled based on the selected frequency as shown below.

recurr1

Navigate to ESSAPP –> Job Requests –> Submit Job Request and select the job definition as shown below. Go to Schedule section and click search icon for Use existing schedule.

jobsubmission

Select the appropriate schedule and click OK.

selectschedule

schsubmission2

To see submitted requests, navigate to ESSAPP->Job Requests –> Search Job Requests and do search for this job.

searchjobreq

In the above screenshot, you can observe 3 requests (used 3 as the count in Schedule) have been submitted as child jobs. Click on Parent ID and Request ID to see more information on these job requests.

parentreq

childreq

Using EM Console to Create Schedule

We can also create a schedule using EM console directly as shown below.

emnewsch

emnewsch1

emnewsch2

emnewsch3

SOA 12c–Creating ESS Job metadata (JDeveloper)

In the previous post, We have seen how to use EM Console to create the Job metadata. This did not provide the much information about development and deployment details of ESS application. So in this post, we will use JDeveloper to create ESS Job metadata to call the Service Bus proxy services however the steps remain same for BPEL services too.

Before proceeding with actual creation of job metadata, we will know the terms Hosting and Client Applications.

Hosting Application

ESS Jobs always execute in context of hosting application. When we configure domain for ESS, we get EssNativeHostingApp which is pre-deployed native hosting application that is well suited for custom remote jobs like EJB and web service jobs. However, we can’t execute custom Java jobs.

Client Application

Client applications are typically J2EE application used to submit jobs, query job status and optionally perform updates to ESS metadata. We cannot add ESS job metadata (using MAR archive) directly to the pre-deployed native hosting application and have to deploy through a client application or using metadata API.

More information can be found in ESS documentation here

Creating ESS Application

Select File –> New –> Applications –> Custom Application as shown below.

essappl

Enter Application Name.

essappl1

Choose the Project Features as shown below and click Next.

essproj

essproj1

Choose the EJB Version and select Generate ejb-jar.xml as shown below.

essproj2

Enter a meaningful value for Application Id.

essproj3

Click Finish and verify that following files got generated in project.

essappl2

Creating Job Metadata – Job Definition

Create Job Definition following the screenshots below. Select File-> New –> Enterprise Scheduler Metadata –> Job Definition.

jobdefn

Enter Job name. Since we are going to call a OSB Synchronous service select the corresponding Job type as shown below. Make sure that location includes essmeta directory.

osbtype

Note that MW_HOME env variable has to be set as shown below to be able to see and select Job Type.

envvar

Click Web service icon to select the WSDL.

osbjobdefn

Select Service Bus as web service type and click search icon.

wsdlsel

Enter Service Bus Proxy Service WSDL as shown below and click OK. Make sure that you give the URL of concrete WSDL.

wsdlurl

Verify that Service and Port Type are automatically populated. Select the operation and parameterize payload using ESS_REQ as shown below. This context is used to access ESS Parameters defined for Job. Hence we need to create CustomerId parameter. Click OK.

wsdlsel1

Verify that System Properties are populated as shown below.

jobdefnafterwsdl

Click + in Application Defined Properties section and add CustomerId parameter as shown below and click OK.

argument1

Since our job should run in context of the pre-deployed hosting application EssNativeHostingApp, add parameter SYS_effectiveApplciation in System Properties section as shown below.

sysprop

weblogic-application.xml

Make sure you only have the following library references in this file.

<listener>
   <listener-class>oracle.mds.lcm.weblogic.WLLifecycleListener</listener-class>
</listener>

<library-ref> 
   <library-name>oracle.ess.thin.client</library-name>
</library-ref>
 

ejb-jar.xml

Add following contents in this file (See the Observations section below).

<enterprise-beans>
    <session>
        <description>Runtime Session Bean</description>
        <ejb-name>RuntimeServiceBean</ejb-name>
        <ejb-class>oracle.as.scheduler.ejb.RuntimeServiceBean</ejb-class>
    </session>
    <session>
        <description>Metadata Session Bean</description>
        <ejb-name>MetadataServiceBean</ejb-name>
        <ejb-class>oracle.as.scheduler.ejb.MetadataServiceBean</ejb-class>
    </session>
    <session>
        <description>Async Request Bean</description>
        <ejb-name>AsyncRequestBean</ejb-name>
        <ejb-class>oracle.as.scheduler.ejb.AsyncRequestBean</ejb-class>
    </session>
</enterprise-beans>

adf-config.xml

If the EAR file generated from this application is to be deployed, certain MDS partition entries must be specified in this file, so add the following contents. The data source referenced here is automatically created when we configure the domain to include ESS. The namespace mentioned over here (highlighted below) should match the package structure we used for creating job definition.

<adf-mds-config xmlns="http://xmlns.oracle.com/adf/mds/config">
    <mds-config version="11.1.1.000" xmlns="
http://xmlns.oracle.com/mds/config">
        <persistence-config>
            <metadata-namespaces>
                <namespace path="/oracle/apps/ess/custom/osb" metadata-store-usage="ess_custom_metadata"/>
            </metadata-namespaces>
            <metadata-store-usages>
                <metadata-store-usage id="ess_custom_metadata" deploy-target="true" default-cust-store="false">
                    <metadata-store class-name="oracle.mds.persistence.stores.db.DBMetadataStore">
                        <property name="jndi-datasource" value="jdbc/mds-ESS_MDS_DS"/>
                        <property name="repository-name" value="mds-ESS_MDS_DS"/>
                        <property name="partition-name" value="essUserMetadata"/>
                    </metadata-store>
                </metadata-store-usage>
            </metadata-store-usages>
        </persistence-config>
    </mds-config>
</adf-mds-config>

Deployment

We have to create the following deployment profiles to be able to deploy:

  • Project level EJB JAR deployment profile.
  • Application level MAR deployment profile.
  • Application level EAR deployment profile

EJB JAR Deployment Profile

Use the following screen shots to create project level EJB JAR profile.

ejbjar1

ejbjar2

ejbsource

ejbjar3

ejbjar4

MAR Deployment Profile

Use the following screen shots to create application level MAR profile.

mar1

marcontent

maressmeta

maressmeta1

maressmeta2

EAR Deployment Profile

Use the following screen shots to create application level EAR profile.

earprofile

earprofile1

earmanifest

earlib

Deployment

Deploy the EAR file of ESS application as shown in following screenshots.

deployess1

deployess2

deployess3

deployess4

deployess5

Here, essUserMetadata is partition used by EssNativeHostingApp. We can observe deployment log as shown below.

deploylog

Submitting the request

In EM Console, navigate to Scheduling Services –> ESSAPP-> Job Requests –> Submit Job Request. Select application as EssNativeHostingApp and choose the job definition as below and select OK.

jobdefnsub

jobdefnsub1

Once the job run is successful, you can see the status as shown below.

reqsuccess

The sample application can be downloaded from here.

Observations

  • Though we add only ESS Job Support and ESS Client Support features during application creation, we see ESS Host Support as well in Project feature section as shown below.

projfeatures

  • Unable to see the Job definitions in ESS while submitting requests, when used package structure (which is effectively a namespace) that does not contain /oracle/apps/ess. Section 1.2.10 of this documentation clearly mentioning that the  job definition must be created in  the namespace /oracle/apps/ess/custom.
  • Unable to refer the WSDL from SOA_MDS or File System in the Web Service chooser during Job definition creation and is resulting into the following error as shown below.

mdswsdl

mdswsdl1

  • The data source mds-ESS_MDS_DS is to be  targeted to AdminServer as shown below, so that we will be able to select data source during deployment.

    essds

  • Initially thought, there is no need of ejb-jar.xml in this ESS application as it’s used predominantly to specify Application Name. But was getting following error during deployment when this file is not present in application or the file has empty contents. So at minimum, this file should have the contents as mentioned above.

         <May 19, 2015 8:47:48 PM IST> <Error> <Deployer> <BEA-149205> <Failed to initialize the application "Ear_EssSampleAppl" due  to error weblogic.management.DeploymentException: Error parsing META-INF/application.xml weblogic.management.DeploymentException: Error parsing META-INF/application.xml


Pages

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 196 other subscribers

Enter your email address to follow this blog and receive notifications of new posts by email.