Deploying ValidatePayment to the OTN SOA VM

The Oracle SOA product management team does a nice job of publishing a Pre-built Virtual Machine for SOA Suite. They also produce an exceptional Oracle SOA Suite 12.1.3 end-to-end tutorial. As I often use the solutions from that tutorial as a baseline for demonstrating other SOA features, such as BAM or API Management, I wanted to document the steps to getting the tutorial’s ValidatePayment composite deployed to the pre-built virtual machine. This primarily involves importing the sample data and configuring the ValidatePayment composite to use the compact domain configured with the VM rather than the integrated domain.

Step 1: Download Resources

Step 2: Configure the Database

Create a SOA_TUTORIAL User

  1. Start SQL Developer (use the icon on the destkop)
  2. Enter the following commands:
    CREATE USER SOA_TUTORIAL IDENTIFIED BY SOA_TUTORIAL;
    GRANT CONNECT, RESOURCE TO SOA_TUTORIAL;
    GRANT UNLIMITED TABLESPACE TO SOA_TUTORIAL;

    01_CREATE_SOA_TUTORIAL

Import Tutorial Sample Data

  1. Start JDeveloper (use the icon on the desktop)
  2. Open the Databases Windows (Window > Database > Databases)
  3. Create a new IDE Connection:
    • Connection Name: SOA_TUTORIAL
    • Connection Type: Oracle (JDBC)
    • Username: SOA_TUTORIAL
    • Driver: thin
    • Host Name: localhost
    • SID: ORCL
    • Test Connection
      02_CREATE_DB_CONN
  4. Open e2e_1201_create_all_tables_oracle.sql in JDeveloper.
  5. Comment out the COMMIT at the end of the script as the JDBC driver will auto commit the changes.
  6. Select SOA_TUTORIAL in the connection dropdown in the upper right and press F5 to run the script.
    03_RUN_SCRIPT
  7. Close the e2e_1201_create_all_tables_oracle.sql script.

Step 3: Open the Validate Payment Solution in JDeveloper

The ValidatePayment solution provided with the tutorial is configured to use the integrated SOA server along with the JavaDB database that’s configured with the integrated server. We need to change the configuration to use the compact domain along with the Oracle Database we just configured.

  1.  Expand SOASuite12c_Tutorial > e2e-1201-orderprocessing > solutions > ch2-validatePayment and extract e2e-1201-composites-ch2.zip.
  2. Open in JDeveloper e2e-1201-composites > e2e-1201-composites.jws. Select Yes on the Open Warning that the application is going to be migrated to 12.2.1.

Update the Database Adapter

  1. Open the ValidatePayment composite.
  2. Double-click the getPaymentInformation to start the Database wizard.
  3. Click Next and the wizard will complain about the missing connection.

    04_CONN_WARN

  4. Click OK and then click the magnifying class to select the SOA_TUTORIAL connection we just established.
  5. Set the JNDI Name to eis/DB/SOA_TUTORIAL. We will configure this soon.

    05_SERVICE_CONN

  6. Click Next to walk through the remainder of the wizard. Nothing else has to change. Click Finish at the end.

Update the Address Location

  1. Open SOA > WSDLs > ValidatePayment_concrete.wsdl. Select the validatePaymentPort service address and change the port from 7101 to 8001.

    051_EDIT_WSDL1

    052_EDIT_WSDL2

  2. Save the close the WSDL.

Step 4: Start the SOA Domain

  1. Open the SOA Domain folder on the desktop and click Start soa_domain Admin Server. Monitor the terminal window that opens and wait for startup to complete.

    06_SOA_DOMAIN

  2. Start the soa_domain SOA Server.

Configure the SOA_TUTORIAL Datasource

  1. Start Firefox.
  2. Use the WLS > WLS Admin Console – SOA and Insight Domain bookmark to open the Admin Console.
  3. Login using weblogic / welcome1.
  4. Select Data Sources.
  5. Create a New > Generic Data Source.
  6. Set the Name to SOA_TUTORIAL_DS and the JNDI Name to jdbc/SOA_TUTORIAL. Leave the Database Type as Oracle.

    07_DS_PROPS

  7. Click Next and select *Oracle’s Drive (Thin XA) for Instance connections: Versions:Any for the Database Driver.

    08_DS_DRIVER

  8. Click Next and Next and set the following:
    Database Name: ORCL
    Host Name: localhost
    Port: 1521
    Database User Name: SOA_TUTORIAL
    Password: SOA_TUTORIAL
    Confirm Passord: SOA_TUTORIAL

    09_DS_CONN
  9. Click Next and Test Configuration. Ensure the test succeeded:

    10_DS_TEST

  10. Click Next and target the datasource to the soa_server:

    11_DS_TARGET

  11. Click Finish.

Update the DB Adapter

Here we will map the JNDI name we configured in our composite, eis/DB/SOA_TUTORIAL, to the data source we just configured.

  1. Click Deployments.
  2. Find and click DbAdapter.
  3. Select the Configuration Tab and Outboud Connection Pools tabs.
  4. Click New.
  5. Select the javax.resource.cci.ConnectionFactory and click Next:

    12_CONN_GROUP

  6. Set the JNDI Name to eis/DB/SOA_TUTORIAL (which matches the name of the DB Adapter in our composite)

    13_JNDI

  7. Click Finish and OK to save the deployment plan:

    14_SAVE_DP

  8. Return to Configuration > Outbound Connection Pools. Expland the javax.resource.cci.ConnectionFactory and click the eis/DB/SOA_TUTORIAL factory we just created:

    15_EDIT_CF

  9. Set the XADataSourceName to jdbc/SOA_TUTORIAL. This maps the connection factory to the data soure we created earlier.

    16_SET_DS

  10. Click Save.
  11. Click Deployments and find the DbAdapter again.
  12. Select the checkbox in the first column and click Update.

    17_UPDATE

  13. Click Next and Finsh. You should see the message:

    18_MESSAGE

Step 5: Deploy Validate Payment

  1. Return to JDeveloper. Right-click the ValidatePayment project and select Deploy > ValidatePayment to open the Depoy wizard.
  2. Select Deploy to Application Server and click Next:

    19_DEPLOY

  3. Select Overwrite any existing composites with the same revision ID. This selection isn’t required for this initial deployment, but we will use it on subsequent deployments. Click Next.

    20_DEPLOY2

  4. Select SOA_DOMAIN and click Next.

    21_DEPLOY3

  5. Select soa_server1 and click Next and Finish.

    22_DEPLOY4

  6. The Deployment – Log should indicate a successful deployment:

    32_DEPLOY_LOG

Step 6: Test Validate Payment Composite

  1. Use the EM > Oracle Enterprise Manager – SOA and Insight Domain bookmark in Firefox to open Enterprise Manager Fusion Middleware Control.
  2. Login using weblogic / welcome1.
  3. Using the Target Navigation menu on the left, switch to SOA > soa-infra (soa_server1)
    24_TARGET_NAV
  4. Switch to the Deployed Composites tab where you should find ValidatePayment.

    25_DEPLOYED_COMPOSITES

  5. Select ValidatePayment and click the Test button.

    26_VALIDATE_PAYMENT

  6. The tutorial includes sample payload we can use to test the service. Under the Request tabl of the Test Web Service page click the Browse button and open SOASuite12c_Totorial > e2e-1201-orderprocessing > sample_input > PaymentInfoSample_Authorized_soap.xml:

    27_TEST

  7. Click Test Web Service. You should see a response status as “Authorized”:

    28_RESPONSE

 

Congratulations, you have successfully deployed the Validate Payment composite to the SOA 12c virtual machine.

 

Advertisements

An Introduction To Oracle API Manager

API Management is a hot topic these days. Back in September, Oracle announced the availability of the Oracle SOA and API Manager Cloud Services. This article will give you an introduction to the latter. If you have an Oracle SOA Cloud Service subscription or an local installation of Oracle API Manager, you can follow along.

For the purpose on this introduction I’m going to start with a Hello World SOAP based web service and use Service Bus to expose the service with a REST interface.

This article will look at API Management from the perspective 0f 3 personas: an API Developer (or curator), an API Admin and an API Consumer. These roles are described with more detail in Understanding User Roles in Oracle API Manager.

We will begin as the API Developer and publish an API to the API Manager. One job of the API developer is to shape or curate the APIs into a form that is potentially more consumable then those provided directly by the source application. One example of this could be to provide a simple interface to a complex ERP API. In this simple example, I will be converting a SOAP based web service into a more mobile friendly REST based web service.

After the API is developed, we will assume to the role of an API Admin and create users that are allowed to consume my APIs.

We will then assume the role of an of an API Consumer. This user is developing an application and would like to consume the hello world API provided by the API Developer.

We will conclude as the API Admin, looking at subscription and performance metrics.

Prerequisites

An API Manager Cloud Service Instance has been provisioned. Alternatively, these instructions will also work with the on-premises version of Oracle API Manager.

Persona 1 – API Developer

We already have an API which we want to shape and virtualize using Oracle Service Bus. For this exercise, we will be exposing a SOAP based web service as REST.

Step 1 – Create a Service Bus Application and Import WSDL

Using JDeveloper 12.1.3, create a new Service Bus Application with Service Bus Project. I’ll call the application HelloWorldApp and the project HelloWorld.

CreateServiceBusApplication

Create a new a folder for the WSDL file:

Right-click the WSDLs folder and select Import and then Service Bus Resources:

In Step 1 of the wizard, select Resources from URL:

Click Next, ensure the Resource Type is WSDL and paste the following into the Source URL field: http://129.152.144.28/soa-infra/services/default/HelloWorld-XYZ/helloworldbpelprocessxyz_client_ep?WSDL.

Click Next and then Finish:

Step 2 – Create Business and Proxy Pipeline Services

Open the HelloWorld Service Bus Overview and drag an HTTP Technology adapter into the External Services lane to create a business service. Name the service HelloWorldBS and leave the Transport as http:

Advance to the next page of the wizard, set the Service Type to WSDL-based service and click the Browse WSDLs icon. Select the WSDL we just imported:

Click Next and Finish.

Drag a Pipeline into the Pipelines/Split Joins swim lane and set the Service Name to HelloWorldPP:

Click Next and set the Service Type to the same WSDL we used for the Business Service. Deselect the option to Expose as a Proxy Service.

Click Finish and wire the HelloWorldPP to the HelloWorldBS:

Step 3 – Expose as Rest

Right-click the HelloWorldPP and select Expose As REST to launch the Create REST binding wizard:

Set the Name to HelloWorldRS and the Resource Path to /hello:

Double-click the process Operational Binding to open the REST Operational Binding editor. Change the URI Parameter from input to name:

Switch to the Response tab. Select JSON as a Payload type.

You can optionally click the Generate Sample Payload button to see what your response will look like in both XML and JSON format:

Click OK, OK and OK to complete the wizard. Save all.

Step 4 – Deploy to API Manager Cloud Service

Right-click the HelloWorld project and select Export and then select Service Bus Resources:

Select Configuration Jar as the Type:

Click Next and select a Export Destination for the Jar File:

Click Finish.

Log into your Oracle Cloud account and navigate to your API Manager Service instance. Then click the hamburger icon in the upper right and select the option to Open API Manager Console. Note, this will actually open the Service Bus Console, which is what we want:

In the Service Bus Console, click Create to start a new session. The click the Import Config Jar icon:

Select the Config Jar we just exported:

Click Next:

Accept all the defaults and click Import.

Activate the session:

Step 5 – Test the Services

Open the HelloWorldBS and click the green arrow to Launch Test Console. Optionally change the input string and click Execute. You should see results similar to those below:

If all goes well, open the HelloWorldRS and click the green arrow to Launch Test Console. Set the Accept as either application/xml or application/json and provide a name:

Click Execute:

Step 6 – Determine API URL

Testing the API w/in Service Bus is easy. Determining the URL to test the API outside of Service Bus takes some investigative work. In my example, I’m running a single managed server node without a load balancer running at IP address 129.152.146.143:

Therefore, the beginning of my API URL is http://129.152.146.143 (the same address I’ve been using the access the Service Bus Console). If I had a load balancer in place, I would use that IP address instead.

If I log into the the Oracle WebLogic Server Console I see that Service Bus is running on APIManag_server_1 at port 8001. The Oracle Cloud VM automatically routs port 80 to port 8001, so I don’t need to specify the port in my URL.

Return to the Service Bus Console and select the Transport tab of the HelloWorldRS service:

I need to append the Endpoint URI to my base URL. So now I have http://129.152.146.143/HelloWorld/HelloWorldRS.

Finally, I need to specify the resource and optional parameter. If you recall our work in JDeveloper in Step 3, we defined the resource as /hello and the parameter as name. Therefore, our complete API URL is:

http://129.152.146.143/HelloWorld/HelloWorldRS/hello?name=<provided name>

If you try to run the API above you will be presented with an Error 403–Forbidden. This is because the API is under the control of the Oracle API Manager and requires an application key (covered next).

Step 7 – Curate the API

Next we will provide metadata on the API which will be published to the API Manager Portal. For more information on this topic, please see Curating APIs Using Oracle Service Bus.

Click the Edit button for the Overview section and provide some details about your API. Don’t forget to include a Test URL so folks know how to use it.

Click Save and then Edit the Publish Status. Set the Status to Published and select Managed. Setting the API to Managed will require a key to be provided to access the service. Click Save.

At this point, our role as an API Developer is complete.
We will now assume the role of an API Admin.

Persona 2 – API Admin

Before APIs can be consumed, users with the application role API Consumer need to first be created so they can log into the API Manager Console.

Step 1 – Create API Consumer Account(s)

For this step we will use the Enterprise Manager Console. We will first create new Group, API Consumers. We will then assign the API Consumer application role to that group. We will then create new users, assigning them to the API Consumers group, therefore inheriting the API Consumer role. Make sense?

Just as we launched the API Manager Console (Oracle Service Bus) in Step 4 above, click the hamburger icon from the API Manager service instance page and launch Oracle Fusion Middleware Control.

Create the API Consumers Group

From the WebLogic Domain dropdown menu, select Security > Users and Groups:

Select the Groups tab and Create a new group, API Consumers:

Assign the APIConsumers role to the API Consumers Group

We need to authorize this new group to access the API Manager Console. From the WebLogic Domain dropdown menu, select Security > Application Roles. Set the Application Stripe to API_Manager and click the blue arrow to Search application roles.

Select the APIConsumer role and click the Edit button. Then add the API Consumers group as a member of the APIConsumer role:

Create Users that can access the API Manager Console

Return to the Security > Users and Groups page. Select the Users tab and Create a new user, APIConsumer. Set a Password for that user.

Edit the APIConsumer user just created, select the Groups tab, and add the user to the API Consumers group:

Create additional user accounts and assign to the API Consumers group as needed.

Note, You can also use an LDAP Authentication provider to manage users. See “Configuring LDAP Authentication Providers” in Administering Security for Oracle WebLogic Server for more information.

Step 2- Enable Analytics

While we are in Enterprise Manager, let’s ensure our operations are being monitored. From the Target Navigation pane on the left, select SOA > service-bus. Then select the Operations tab and click Search. Enable Monitoring for all services and click Apply:

If you skip this step, you will not see any performance metrics in the API Manager Console.

Persona 3 – API Consumer

Now that an API has been made available, let’s put it to use…

Step 1 – Subscribe to the API

Log into the API Manager Portal using the newly created user account, in my case APIConsumer. The application URL is https://<instance IP address:7001/apimanager. In my case, https://129.152.146.143:7002/apimanager. You may want to do this in a private browsing window so that it doesn’t automatically log you in as the weblogic user. The weblogic (admin) user doesn’t have the necessary privileges to create applications and consume APIs.

After logging in you will be greeted by the welcome screen:

From here we can create and manage our applications or browse the API catalog. Since our goal is to consume an API for our application, let’s start there. Click the Red Create and Manage circle to navigate to the Subscriptions page:

We have no API subscriptions or applications. Click the New Application button then provide a Name and Description:

Click Create. Notice the Key that has been provided. This is the key that will need to be provided in order to access the API.

The next step is to add APIs to the application. Clicking Add API takes you to the API catalog. Here you can begin to see some of the metadata we provided in the Service Bus console:

Click the blue information icon to see even more details:

Return to the Hello World REST Service and click the check box icon (next to the information icon) to select the API. Then click the Subscribe button. Now our Greetings application is subscribed to the API.

Step 2 – Consume the API

To test consumption of the API, use your favorite REST client. This could be SOAP UI, RESTClient, Advanced Rest Client, or any number of viable alternatives. At a minimum you need to include the X-API-KEY header:

X-API-KEY: 518a50b7-a7b1-4f4d-8bcb-28d92d296f0d

Since I also want JSON instead of XML returned, I also set the Accept: application/json header:

Persona 2 (again) – API Admin

Monitor Usage

In order to see usage statistics, the API Manager user must be assigned the APIApplicationAdministrator application role, which my APIConsumer user does not possess. However, my weblogic user does have this role. I can see subscriptions by User or API. Below is the User view. Note I can also see applications w/out any subscriptions as well as unused APIs:

I can also view the performance analytics:

Happy API Managing!

Browsing Your Developer Cloud Service Maven Repository Using Cyberduck

Every Developer Cloud Service project includes a Maven repository:

repositories

Cyberduck is a free FTP, SFTP, WebDAV, S3 & OpenStack Swift browser for Mac and Windows. Thus, using Cyberduck, you can browse your project’s Maven repository.

Start Cyberduck and select Open Connection:

cyberduck

From the Open Connection dialog, select WebDAV (HTTP/SSL) from the drop down. Set the Server, Username and Password. It’s also necessary to expand the More Options an enter the Path. Both the Server and the Path can be extracted from the Maven repository URL provided in your Developer Cloud Service project (mine is shown above):

openconnection

Browse:

browse

Note, if you come across the following Error dialog, it generally means that particular directory is just empty:

error

Automating Deployment of the Summit ADF Sample Application to the Oracle Java Cloud Service

Back in April, Shay Shmeltzer produced a video explaining how to automate the build of ADF applications using the Oracle Developer Cloud Service. Shay used the Summit ADF sample application for his example. In this article, I will take the next logical step and show you how to automate the deployment of the Summit ADF sample application to the Oracle Java Cloud Service.

Prerequisites

Step 1: Install the Summit ADF Schema

See the Instructions to install the schema for the full details. I will hit the highlights for installing the schema to the Oracle Database Cloud Service.

  1. Download and extract the Summit ADF schema.
  2. The scripts directory contains everything that is necessary to create the schema and populate it with sample data:
  3. We are going to run this script in our Database Cloud Service PDB. However, the create_user.sql as provided creates a common user (c##summit_adf), which must be created in the CDB (See Create User for details). Therefore, modify the create_user.sql script as follows:ALTER SESSION set container=CDB$ROOT;

    DROP USER c##summit_adf CASCADE;

    CREATE USER c##summit_adf IDENTIFIED BY summit_adf DEFAULT TABLESPACE users
    TEMPORARY TABLESPACE temp
    QUOTA UNLIMITED ON users;

    GRANT create session TO c##summit_adf container=all;
    GRANT alter session TO c##summit_adf container=all;
    GRANT create table TO c##summit_adf container=all;
    GRANT create trigger TO c##summit_adf container=all;
    GRANT create view TO c##summit_adf container=all;
    GRANT create sequence TO c##summit_adf container=all;
    GRANT create synonym TO c##summit_adf container=all;
    GRANT create type TO c##summit_adf container=all;
    GRANT create procedure TO c##summit_adf container=all;

  4. Secure copy the scripts directory to the oracle user home directory of your Database Cloud Service instance. I found it easiest to use a tool like WinSCP:
  5. Log into your Database Cloud Service Console to find your PDB Name. In my case it’s PDB1:newalphadbcs
  6. SSH into your Database Cloud Service instance as the oracle user and modify the connect string of the build_summit_schema.sql, replacing localhost with your PDB name:
  7. Log into SQL*Plus as the system user and execute the build_summit_schema.sql script

Step 2: Switch the Connection Type

We now need to switch the application connection type from JDBC URL to JDBC DataSource. For details about this step, you can read What You May Need to Know About JDBC Data Source for Oracle WebLogic Server.

  1. In JDeveloper, expand Model > Application Sources > oracle.summit.model > services
  2. Open BackOfficeAppModule
  3. Select Configurations and edit BackOfficeAppModuleLocal. Change the Connection Type from JDBC URL to JDBC DataSource. Also note the Datasource Name: java:comp/env/jdbc/summit_adfDS. We will need the next step when we create the Datasource in the Java Cloud Cloud Service:
  4. Repeat for CustomerSelfServiceAppModule and SummitAppModule.
  5. Commit the changes:
  6. Push the changes to your Developer Cloud Service project (Team > Git > Push).

Step 3: Create the JDBC DataSource

We need to create the data source our application is expecting to find. For details on this section see Creating a JDBC Data Source for Oracle WebLogic Server.

  1. Log into the WebLogic Administrative Console of your Java Cloud Service instance.
  2. Create a New Generic Data Source. Set the JNDI name to jdbc/summit_adfDS (Applications lookup a data source on the JNDI tree at java:comp/env/, so we exclude this portion of the Datasource Name. See Understanding JDBC Resources in WebLogic Server for details.):createnewjdbcdatasource
  3. On the JDBC Data Source Properties page, set the Database Driver to *Oracle’s Driver (Thin) for Service connections; Versions:9.0.1 and later (Fusion web applications are not compatible with data sources defined with the JDBC XA driver. See What You May Need to Know About JDBC Data Source for Oracle WebLogic Server for details):createnewjdbcdatasource2
  4. On the Transaction Options page, the defaults are fine:
  5. On the Connection Properties page, set the Database Name and Host Name from the Connect Descriptor found on your Database Cloud Service Console. This is the same page in Step 1-4 above where we grabbed the PDB Name. The Database User Name is c##summit_adf and the Password is summit_adf.
  6. On the Test Database Connection page, click Test Configuration:
  7. On the Select Targets page, select All Servers in the cluster and then click Finish:createnewjdbcdatasource6

Step 4: Create Deployment Artifacts

At the end of Shay’s video, we have a working build but no build artifacts:

In order to create a new deployment configuration, we need to configure our build to generate the artifacts. Looking at the Git Log from the previous build, you can see the location where the ear was generated:

[ora:ojdeploy] [06:24:38 PM] Deploying 2 profiles...
   [ora:ojdeploy]   file:/home/c2c/hudson/workspace/developer43881-wbrianleonard_cloudsandboxapplication.SummitBuild/ViewController/ViewController.jpr
   [ora:ojdeploy] [06:24:40 PM] Wrote Web Application Module to file:/home/c2c/hudson/workspace/developer43881-wbrianleonard_cloudsandboxapplication.SummitBuild/ViewController/deploy/SummitADF_ViewController_webapp1.war
   [ora:ojdeploy]   SummitADF_ViewController_webapp1:ViewController.jpr
   [ora:ojdeploy] [06:24:40 PM] Wrote Enterprise Application Module to file:/home/c2c/hudson/workspace/developer43881-wbrianleonard_cloudsandboxapplication.SummitBuild/SummitADF/ViewController/deploy/SummitADF_application1.ear
   [ora:ojdeploy] [06:24:40 PM] Elapsed time for deployment:  7 seconds
 [ora:ojdeploy] [06:24:40 PM] ----  Deployment finished.  ----

Note the EAR file is written to SummitADF/ViewController/deploy/SummitADF_application1.ear. Let’s configure our build to archive all artifacts in the SummitADF/ViewController/deploy/ directory.

  1. In the Developer Cloud Service, edit the SummitBuild Configuration.
  2. Expand the Post-build Actions and check Archive the artifacts.
  3. Set the Files To Archive to SummitADF/ViewController/deploy/*
  4. Save and then click Build Now.
  5. When the build completes, you’ll see the following artifacts:
    There are actually two EARs created, let’s return to JDeveloper to investigate.

Step 5: Investigate Deployment Profiles

    1. View the Summit ADF Application Deployment Properties (Application > Application Properties). Here you can see the two Deployment Profiles which map to our generated EAR files:
    2. If you look at the modules that make up each of these profiles, you’ll notice neither appear to have everything we need. Model_Summit_Interface:SummitADF_Application1:The Model_Summit_Interface has an reference to an EJB interface. I don’t believe the core version of this application has EJBs. The SummitADF_Application1 profile only references the ViewController, so that won’t work either. Let’s investigate further.
    3. View the Model project’s Deployment Profiles. We can see the deployment profiles that were available from the Application Assembly. However, none of these profiles seem to fit the bill, as this project is using ADF Business Components:
    4. I’m going to delete all of these profiles and create a new profile of type Business Components Archive:
    5. I’m then going to delete the application profiles, and create a new deployment profile:
    6. The new Application Deployment Profile will contain my new Model module as well as the existing ViewController module (which was OK):

Step 6: Commit and Push the Changes to Developer Cloud Service Project

  1. Switch to the Pending Changes window:
  2. Add the changes:
  3. Commit the Changes:
  4. And Push the changes to the Developer Cloud Service (Git > Push).
  5. The push will automatically trigger a Git build. When the build completes, we will have our single, complete, deployment artifact:

Step 7: Deploy Summit ADF to Java Cloud Service

Oracle Developer Cloud Service deploys applications to the Oracle Java Cloud Service server through an SSH tunnel. If not already configured, follow the steps at Installing the Oracle Developer Cloud Service Public Key in the Oracle Java Cloud Service VM to complete this one time exercise.

    1. In the Developer Cloud Service, Switch to the Deploy tab.
    2. Click New Configuration and fill in the details. I’ve configured the deploy to occur with each successful build:
    3. For the Java Service, you need to configure the remote target (Java Cloud Service):
    4. Supply the IP address of your Java Cloud Service instance along with your WebLogic server administration credentials (set when you created the JCS instance):
    5. Click Test Connection:
    6. Click Use Connection:
    7. Click Save, which will create the Deployment:
    8. Right-click the gear and select Start:
    9. Wait while the application is started:
    10. But unfortunately, deployment fails:
    11. Looking at the log file, we can see that:
      Target state: deploy failed on Cluster Alpha01J_cluster  weblogic.common.ResourceException: No credential mapper entry found for password indirection user=summit_adf for data source summit_adf

Step 8: Fix Deployment Error

Our problem (like all of our other problems thus far) is that the Summit ADF sample application is configured to deploy to JDeveloper’s Integrated WebLogic Server. If we revisit What You May Need to Know About JDBC Data Source for Oracle WebLogic Server, we need to disable the Auto Generate and Synchronize weblogic-jdbc.xml Descriptor During Deployment option. This option isn’t necessary because we switched the connection type from JDBC URL to JDBC DataSource.

After making, committing and pushing this change, the Summit ADF application will build and deploy successfully:

Step 9: Run

I’ve deployed this application to a single node JCS cluster without a load balancer, so we will hit the managed server directly. The URL is http://129.152.144.180/SummitADF-ViewController-context-root/faces/index.jsf.

Hello (again) world!

I’m a blogger looking for a new platform. After years of blogging at Java.net and blogs.sun.com, I’ve decided to give WordPress a try. Two sentences in and I really like what I’m experiencing. There’s no cadence to my blogging. Rather I try to blog when I figure out something interesting and I want a record in case I need to repeat it. To that point, I’m probably the most avid reader of my blog, but if it’s a benefit to others, all the better. Throughout my career I’ve blogged primarily about NetBeans and OpenSolaris (RIP). My newest hobby, and the general topic of this blog will be the Oracle Public Cloud.