WebLogic Server 12.2.1.3.0 - Get Patch List with RESTful Management Services

Yesterday, I discovered a new field within the RESTful Management Services under serverRuntime - patchList.

This new field contains the list of applied patches to your Oracle WebLogic Server 12.2.1.3.0 installation, so I thought, I will not longer need to access opatch lsinventory to retrieve the list of applied patches on my WebLogic Server installation ...

You can check the list of applied Patches with following URL call within a browser or just use a curl command:
http://<servername>:<port>/management/weblogic/latest/serverRuntime?links=none&fields=patchList

Now lets compare the above list with opatch lsinventory.

cd $ORACLE_HOME/OPatch
./opatch lsinventory
Oracle Interim Patch Installer version 13.9.2.0.0
Copyright (c) 2017, Oracle Corporation.  All rights reserved.


Oracle Home       : /u00/app/oracle/product/fmw-wls-12.2.1.3.0
Central Inventory : /u00/app/oracle/oraInventory
   from           : /u00/app/oracle/product/fmw-wls-12.2.1.3.0/oraInst.loc
OPatch version    : 13.9.2.0.0
OUI version       : 13.9.2.0.0
Log file location : /u00/app/oracle/product/fmw-wls-12.2.1.3.0/cfgtoollogs/opatch/opatch2017-09-08_12-48-42PM_1.log


OPatch detects the Middleware Home as "/u00/app/oracle/product/fmw-wls-12.2.1.3.0"

Lsinventory Output file location : /u00/app/oracle/product/fmw-wls-12.2.1.3.0/cfgtoollogs/opatch/lsinv/lsinventory2017-09-08_12-48-42PM.txt

--------------------------------------------------------------------------------
Local Machine Information::
Hostname: weblogic122130
ARU platform id: 226
ARU platform description:: Linux x86-64


Interim patches (4) :

Patch  26355633     : applied on Thu Aug 31 14:26:20 CEST 2017
Unique Patch ID:  21447583
Patch description:  "One-off"
   Created on 1 Aug 2017, 21:40:20 hrs UTC
   Bugs fixed:
     26355633

Patch  26287183     : applied on Thu Aug 31 14:26:10 CEST 2017
Unique Patch ID:  21447582
Patch description:  "One-off"
   Created on 1 Aug 2017, 21:41:27 hrs UTC
   Bugs fixed:
     26287183

Patch  26261906     : applied on Thu Aug 31 14:25:53 CEST 2017
Unique Patch ID:  21344506
Patch description:  "One-off"
   Created on 12 Jun 2017, 23:36:08 hrs UTC
   Bugs fixed:
     25559137, 25232931, 24811916

Patch  26051289     : applied on Thu Aug 31 14:25:48 CEST 2017
Unique Patch ID:  21455037
Patch description:  "One-off"
   Created on 31 Jul 2017, 22:11:57 hrs UTC
   Bugs fixed:
     26051289

--------------------------------------------------------------------------------

OPatch succeeded.

Looks so far so good. 4 applied Patches are reported with the RESTful Management Services URL access and the same 4 patches are reported with opatch lsinventory.

Now lets perform the same on an Oracle WebLogic Server 12.2.1.3.0 (Infrastructure) hosting Oracle Forms & Reports 12.2.1.3.0.

RESTful Management Services access http://<servername>:<port>/management/weblogic/latest/serverRuntime?links=none&fields=patchList give me a list of 11 applied patches:

And now the usual crosschecking with opatch lsinventory

cd $ORACLE_HOME/OPatch
./opatch lsinventory
Oracle Interim Patch Installer version 13.9.2.0.0
Copyright (c) 2017, Oracle Corporation.  All rights reserved.


Oracle Home       : /u00/app/oracle/product/fmw-fr-12.2.1.3.0
Central Inventory : /u00/app/oraInventory
   from           : /u00/app/oracle/product/fmw-fr-12.2.1.3.0/oraInst.loc
OPatch version    : 13.9.2.0.0
OUI version       : 13.9.2.0.0
Log file location : /u00/app/oracle/product/fmw-fr-12.2.1.3.0/cfgtoollogs/opatch/opatch2017-09-08_13-16-42PM_1.log


OPatch detects the Middleware Home as "/u00/app/oracle/product/fmw-fr-12.2.1.3.0"

Lsinventory Output file location : /u00/app/oracle/product/fmw-fr-12.2.1.3.0/cfgtoollogs/opatch/lsinv/lsinventory2017-09-08_13-16-42PM.txt

--------------------------------------------------------------------------------
Local Machine Information::
Hostname: fr122130
ARU platform id: 226
ARU platform description:: Linux x86-64


Interim patches (14) :

Patch  26248143     : applied on Fri Sep 01 13:47:48 CEST 2017
Unique Patch ID:  21362003
   Created on 26 Jun 2017, 11:23:19 hrs PST8PDT
   Bugs fixed:
     26248143
   This patch overlays patches:
     24732082
   This patch needs patches:
     24732082
   as prerequisites

Patch  25549931     : applied on Fri Sep 01 13:46:55 CEST 2017
Unique Patch ID:  21137755
   Created on 20 Apr 2017, 02:55:44 hrs PST8PDT
   Bugs fixed:
     25549931

Patch  24737021     : applied on Fri Sep 01 13:46:08 CEST 2017
Unique Patch ID:  21289586
   Created on 22 May 2017, 04:19:02 hrs PST8PDT
   Bugs fixed:
     24737021

Patch  22754279     : applied on Fri Sep 01 13:45:25 CEST 2017
Unique Patch ID:  20383951
Patch description:  "One-off"
   Created on 9 Jul 2016, 00:36:58 hrs UTC
   Bugs fixed:
     22754279

Patch  21663638     : applied on Fri Sep 01 13:44:30 CEST 2017
Unique Patch ID:  20477024
Patch description:  "One-off"
   Created on 31 Aug 2016, 21:01:13 hrs UTC
   Bugs fixed:
     21663638

Patch  19795066     : applied on Fri Sep 01 13:43:29 CEST 2017
Unique Patch ID:  19149348
Patch description:  "One-off"
   Created on 16 Jul 2015, 15:51:43 hrs UTC
   Bugs fixed:
     19795066

Patch  19632480     : applied on Fri Sep 01 13:42:49 CEST 2017
Unique Patch ID:  19278519
Patch description:  "One-off"
   Created on 25 Aug 2015, 07:19:43 hrs UTC
   Bugs fixed:
     19632480

Patch  19154304     : applied on Fri Sep 01 13:42:13 CEST 2017
Unique Patch ID:  19278518
Patch description:  "One-off"
   Created on 25 Aug 2015, 07:10:13 hrs UTC
   Bugs fixed:
     19154304

Patch  19030178     : applied on Fri Sep 01 13:41:36 CEST 2017
Unique Patch ID:  19234068
Patch description:  "One-off"
   Created on 4 Aug 2015, 05:40:22 hrs UTC
   Bugs fixed:
     19030178

Patch  24732082     : applied on Fri Sep 01 13:41:00 CEST 2017
Unique Patch ID:  20904347
Patch description:  "Database Patch Set Update : 12.1.0.2.170117 (24732082)"
   Created on 21 Dec 2016, 07:15:01 hrs PST8PDT
Sub-patch  24006101; "Database Patch Set Update : 12.1.0.2.161018 (24006101)"
Sub-patch  23054246; "Database Patch Set Update : 12.1.0.2.160719 (23054246)"
Sub-patch  22291127; "Database Patch Set Update : 12.1.0.2.160419 (22291127)"
Sub-patch  21948354; "Database Patch Set Update : 12.1.0.2.160119 (21948354)"
Sub-patch  21359755; "Database Patch Set Update : 12.1.0.2.5 (21359755)"
Sub-patch  20831110; "Database Patch Set Update : 12.1.0.2.4 (20831110)"
Sub-patch  20299023; "Database Patch Set Update : 12.1.0.2.3 (20299023)"
Sub-patch  19769480; "Database Patch Set Update : 12.1.0.2.2 (19769480)"
   Bugs fixed:
     19309466, 19902195, 18250893, 21172913, 17655240, 21266085, 19028800
. . .
. . .
. . .
     21294938, 20898997, 18510194, 19534363, 19188927

Patch  26355633     : applied on Fri Sep 01 13:33:37 CEST 2017
Unique Patch ID:  21447583
Patch description:  "One-off"
   Created on 1 Aug 2017, 21:40:20 hrs UTC
   Bugs fixed:
     26355633

Patch  26287183     : applied on Fri Sep 01 13:33:24 CEST 2017
Unique Patch ID:  21447582
Patch description:  "One-off"
   Created on 1 Aug 2017, 21:41:27 hrs UTC
   Bugs fixed:
     26287183

Patch  26261906     : applied on Fri Sep 01 13:33:03 CEST 2017
Unique Patch ID:  21344506
Patch description:  "One-off"
   Created on 12 Jun 2017, 23:36:08 hrs UTC
   Bugs fixed:
     25559137, 25232931, 24811916

Patch  26051289     : applied on Fri Sep 01 13:32:56 CEST 2017
Unique Patch ID:  21455037
Patch description:  "One-off"
   Created on 31 Jul 2017, 22:11:57 hrs UTC
   Bugs fixed:
     26051289

--------------------------------------------------------------------------------

OPatch succeeded.

Unfortunately opatch lsinventory reports me 14 applied patches on my environment while the RESTful Management Services reports only 11 patches :-(

Seems that there is a small unexpected feature (some people would call it a bug ...) within the WebLogic Server 12.2.1.3.0 Infrastructure version. I have already started a SR with Oracle about that, lets see what will be the result ..

So summing up, its a really nice enhancement to retrieve your applied patches via a simple URL call or curl command, but be careful depending on your version of the WebLogic Server (Generic or Infrastructure) you might not see the correct list.

Read More

Find all configured SystemComponents in Oracle Fusion Middleware - The RESTFul way

Today, just a quick post on how to find all your configured System Components within an Oracle Fusion Middleware / Oracle WebLogic Server Environment.

Let's say you are having an Oracle Forms & Reports Environment based on an Oracle WebLogic Server. Within your environment you have configured various so called System Components, and you need to know all the names and the corresponding System Component Type, like:

• Oracle HTTP Server (OHS)
• Oracle Reports Standalone Servers
• Oracle Forms

With the Oracle WebLogic Server RESTFul Management Services you are able to list them all by name and including the type of System Component.

Simply run following cURL command against your WebLogic Server hosting your Oracle Fusion Middleware Components:

# Align the password of your Oracle WebLogic User
# Align the hostname and port of your WebLogic Server
curl \
--user weblogic:Oracle12c \
-H X-Requested-By:MyClient \
-H Accept:application/json \
-H Content-Type:application/json \
-d "{
     fields: [ 'name' ], links: [],
      children: {
         systemComponents: {
             fields: [ 'name' , 'componentType'],
             links: []
                            }
                 }
}" -X POST http://localhost:7001/management/weblogic/latest/domainConfig/search

{
    "name": "FRDEVEL",
    "systemComponents": {"items": [
        {
            "componentType": "FORMS",
            "name": "forms1"
        },
        {
            "componentType": "OHS",
            "name": "ohs1"
        },
        {
            "componentType": "ReportsToolsComponent",
            "name": "reptools1"
        },
        {
            "componentType": "ReportsServerComponent",
            "name": "rep_server1"
        },
        {
            "componentType": "ReportsServerComponent",
            "name": "rep_server2"
        }
    ]}

Unfortunately you can not filter over componentType, as this is not a collection and therefor a query restriction on the componentType will be ignored :-(

This method is a bit quicker then going through your $DOMAIN_HOME/system_components folder and get all your configured System Components.

Read More

Consume WebLogic Server RESTFul Management Services with ELK

In several of my projects for Oracle WebLogic Server and Oracle Fusion Middleware Environments a main topic is the monitoring.
Oracle provides with the Oracle Enterprise Manager Cloud Control are really powerful solution to monitor Oracle WebLogic Server and Oracle Fusion Middleware Environments, but the disadvantage is the huge license cost for the necessary Management Packs for Oracle WebLogic / Fusion Middleware. Moreover in many small to midrange sized environments the Oracle Enterprise Manager Cloud Control can be an overkill and due to the license costs for the Management Packs a no-go.

There are several solutions on the market, some commercial and some open source, for Oracle WebLogic Server Monitoring.

I will show you a short test case, how to consume Oracle WebLogic Server RESTFul Management Services with the so called ELK Stack (Elasticsearch / Logstash / Kibana). How to setup the ELK stack, just check Google or the documentation on elastic.co https://www.elastic.co/guide/en/elastic-stack/current/index.html

My environment is as follows:

• Ubuntu 16.04 server named "monitoring" which is hosting my ELK Stack
• Oracle Enterprise Linux named "wls12212" which is hosting my Oracle WebLogic Server with a Domain called demo_domain
• AdminServer running on Port 7001

On the ELK server monitoring add a Logstash configuration file wls-rest.conf under /etc/logstash/conf.d
For this I will use the Input Plugin http_poller (see https://www.elastic.co/guide/en/logstash/current/plugins-inputs-http_poller.html)

input {
  http_poller {
    urls => {
      test1 => {
        method => get
        # define the RESTFul Management Service URL
        url => "http://wls12212:7001/management/wls/latest/servers"
        headers => {
          Accept => "application/json"
        }
        # Define the Basic Authentication against the WebLogic Server
        auth => {
          user => "weblogic"
          password => "welcome01"
        }
      }
    }
    request_timeout => 30
    # poll every 60 seconds the metrics
    interval => 60
    # Set the Codec to json
    codec => "json"
    metadata_target => "http_poller_metadata"
  }
}

output {
  # Output to elasticsearch
  elasticsearch { hosts => ["localhost:9200"] }
  # Output to stdout
  stdout { codec => rubydebug }
}

Now we can start our logstash process on the ELK server monitoring

/opt/logstash/bin/logstash -f /etc/logstash/conf.d/wls-rest.conf
Settings: Default pipeline workers: 1
Pipeline main started
{
                   "items" => [
        [0] {
                   "heapFreeCurrent" => 188998424,
                   "heapSizeCurrent" => 374341632,
                "usedPhysicalMemory" => 3520323584,
                  "jvmProcessorLoad" => 0,
                            "health" => {
                "state" => "ok"
            },
            "activeHttpSessionCount" => 0,
                 "activeThreadCount" => 11,
                              "name" => "DemoAdminServer",
                             "state" => "running"
        },
        [1] {
                   "heapFreeCurrent" => 275771456,
                   "heapSizeCurrent" => 401080320,
                "usedPhysicalMemory" => 3520323584,
                  "jvmProcessorLoad" => 0,
                            "health" => {
                "state" => "ok"
            },
            "activeHttpSessionCount" => 0,
                 "activeThreadCount" => 8,
                              "name" => "DemoMS1",
                             "state" => "running"
        },
. . .
. . .

Now we can check in Kibana the Indices under Settings:

and define our Visualization under Visualize:

With this really simple configuration you can consume all available Metrics within the WebLogic RESTFul Management Services via ELK Stack just by defining the url in the http_poller configuration, visualise them, create dashboard and with the Output Plugins in Logstash (https://www.elastic.co/guide/en/logstash/current/output-plugins.html) you can even define notifications through Email, Nagios, Zabbix and so on ...

Read More

Accessing WebLogic Server Logfiles via RESTFul Management Services

The RESTFul Management Services within Oracle WebLogic 12c is one of the greatest features and my personal favorite.

You can achieve a lot of things with the RESTFul Management Services, like creating DataSources, perform deployments, startup and shutdown Managed Servers and so on.

But you also can access the different WebLogic Server Logfiles :-)

Let's say your developers needs access to the Logfiles of your Oracle WebLogic Server, but you don't want to give them access to your Server which is hosting your Oracle WebLogic Server.
Just create a new User in your WebLogic Admin Console and give this new User the Group "Monitor". With the Monitor Group you can access the WebLogic RESTFul Management Services.

Now your developers can retrieve the Logfiles with a simple cURL command from their desktops:

http://<servername>:<adminport>/management/wls/latest/servers/id/<ServerName>/logs/<LogType>

For the LogType you have following options:

• DataSourceLog
• DomainLog (only for AdminServer)
• HTTPAccessLog
• ServerLog

A possible cURL request to retrieve the DomainLog of your WebLogic Domain could be as follows:

# Replace the Server Name and Port with your values
# Replace the AdminServer Name "PRODAdminServer" with your AdminServer Name
#
curl -s --user RESTAdmin:welcome1 \
        -H X-Requested-By:MyClient \
        -H Accept:application/json \
        -X GET http://wls122:7101/management/wls/latest/servers/id/PRODAdminServer/logs/id/DomainLog > domain.log

or like this:

# Replace the Server Name and Port with your values
# Replace the Managed Server Name "Prod_ManagedServer1" with your Managed Server Name
#
curl -s --user RESTAdmin:welcome1 \
        -H X-Requested-By:MyClient \
        -H Accept:application/json \
        -X GET http://wls122:7101/management/wls/latest/servers/id/Prod_ManagedServer1/logs/id/ServerLog > Prod_ManagedServer1_ServerLog.log

The corresponding Logfile retrieval in JSON format will look as follows:

DomainLog:

Managed Server ServerLog:

Read More

Controlling Oracle WebLogic Server via RESTFul Management Service

RESTFul Management Services are really powerful in terms of monitoring your Oracle WebLogic Server Domain, but you can also use RESTFul Management Services to control your Oracle WebLogic Server Domain.

RESTFul Management Services are enabling you to startup, suspend, resume and shutdown for example your Managed Servers.

All what you need is cURL, the Admin User and Password of your Oracle WebLogic Server, Hostname of your Oracle WebLogic Domain and the Port of your AdminServer.

# cURL syntax to start up the Managed Server called DemoManagedServer1
#
curl -s --user weblogic:welcome1 \
> -H X-Requested-By:MyClient \
> -H Accept:application/json \
> -X POST http://localhost:7001/management/wls/latest/servers/id/DemoManagedServer1/start
{
    "item": {
        "beginTime": 1479137278206,
        "endTime": 1479137293451,
        "status": "completed",
        "description": "Starting DemoManagedServer1 server ...",
        "serverName": "DemoManagedServer1",
        "operation": "start",
        "name": "_0_start",
        "id": "DemoManagedServer1:_0_start",
        "type": "server"
    },
    "messages": [{
        "message": "Started the server 'DemoManagedServer1'.",
        "severity": "SUCCESS"
    }],
    "links": [{
        "rel": "job",
        "uri": "http:\/\/localhost:7001\/management\/wls\/latest\/jobs\/server\/id\/DemoManagedServer1:_0_start"
    }]

# cURL syntax to suspend the Managed Server called DemoManagedServer1
#
curl -s --user weblogic:welcome1 \
> -H X-Requested-By:MyClient \
> -H Accept:application/json \
> -X POST http://localhost:7001/management/wls/latest/servers/id/DemoManagedServer1/suspend
{
    "item": {
        "beginTime": 1479137373341,
        "endTime": 1479137378061,
        "status": "completed",
        "description": "suspending DemoManagedServer1 server ...",
        "serverName": "DemoManagedServer1",
        "operation": "suspending",
        "name": "_1_suspendWithTimeout",
        "id": "DemoManagedServer1:_1_suspendWithTimeout",
        "type": "server"
    },
    "messages": [{
        "message": "Suspended the server 'DemoManagedServer1'.",
        "severity": "SUCCESS"
    }],
    "links": [{
        "rel": "job",
        "uri": "http:\/\/localhost:7001\/management\/wls\/latest\/jobs\/server\/id\/DemoManagedServer1:_1_suspendWithTimeout"
    }]

# cURL syntax to resume the Managed Server called DemoManagedServer1
#
curl -s --user weblogic:welcome1 \
> -H X-Requested-By:MyClient \
> -H Accept:application/json \
> -X POST http://localhost:7001/management/wls/latest/servers/id/DemoManagedServer1/resume
{
    "item": {
        "beginTime": 1479137414870,
        "endTime": 1479137420100,
        "status": "completed",
        "description": "Resuming DemoManagedServer1 server ...",
        "serverName": "DemoManagedServer1",
        "operation": "resume",
        "name": "_2_resume",
        "id": "DemoManagedServer1:_2_resume",
        "type": "server"
    },
    "messages": [{
        "message": "Resumed the server 'DemoManagedServer1'.",
        "severity": "SUCCESS"
    }],
    "links": [{
        "rel": "job",
        "uri": "http:\/\/localhost:7001\/management\/wls\/latest\/jobs\/server\/id\/DemoManagedServer1:_2_resume"
    }]

# cURL syntax to shutdown the Managed Server called DemoManagedServer1
#
curl -s --user weblogic:welcome1 \
> -H X-Requested-By:MyClient \
> -H Accept:application/json \
> -X POST http://localhost:7001/management/wls/latest/servers/id/DemoManagedServer1/shutdown
{
    "item": {
        "beginTime": 1479137450438,
        "endTime": 1479137457385,
        "status": "completed",
        "description": "Shutting down DemoManagedServer1 server ...",
        "serverName": "DemoManagedServer1",
        "operation": "shutdown",
        "name": "_3_shutdown",
        "id": "DemoManagedServer1:_3_shutdown",
        "type": "server"
    },
    "messages": [{
        "message": "Shutdown the server 'DemoManagedServer1'.",
        "severity": "SUCCESS"
    }],
    "links": [{
        "rel": "job",
        "uri": "http:\/\/localhost:7001\/management\/wls\/latest\/jobs\/server\/id\/DemoManagedServer1:_3_shutdown"
    }]

And with a bit of scripting you can create a UNIX Wrapper Shell script to cover all above described startup, suspend, resume and shutdown operations.

Read More

OTN Appreciation Day: WebLogic

Based on the suggestion by Tim Hall's Blogpost here is my contribution to the OTN Appreciation Day:

I've got 2 features and as usual these features are related to Oracle WebLogic Server:

1st Oracle WebLogic Server & Docker

The official support and certification for Oracle WebLogic Server on Docker started nearly one year ago. Since the first support and certification of Oracle WebLogic Server on Docker there were a lot of things happening, support and certification has been continuously extended to the latest release of Oracle WebLogic Server 12.2.1.1, Oracle (specially Bruno Borges) is driving a great GitHub Repository which provides you nearly everything around Oracle WebLogic Server and Docker.

The combination of Oracle WebLogic Server and Docker is really a game changer for how people like me are working now with Oracle WebLogic Server, it forces you to rethink your old techniques on how to design, install, maintain and specially monitor your WebLogic Infrastructure.
But on the other hand it also gives you new opportunities on how to work closer with the Developers (DevOps).

If you want to learn more about Oracle WebLogic Server on Docker, I strongly recommend to have a look on following stuff:

• WebLogic on Docker Workshops
• Oracle WebLogic YouTube Channel
• My Blog :-) How to integrate Critical Patch Updates in your WebLogic Image

2nd Oracle WebLogic Server & RESTFul Management Services

REST is normally more a classical Developer topic, but since Oracle introduced the RESTFul Management Services in Oracle WebLogic Server 12.1.2 it has become also a topic for Administrators. The RESTFul Management Services are providing you the option to monitor your entire Oracle WebLogic Server including all deployed applications, integrated resources like JDBC, JMS and so on, moreover you can administer your entire WebLogic Server, like creating new Managed Servers, deleting resources, deploying applications and so on, just with a http request performed for example by a simple cURL command.
The response performance of cURL based RESTFul Management Service request to retrieve some performance metrics of your WebLogic Server compared to the classical scripting via Python and executed by wlst is simply incredible.
Specially the RESTFul Management Services are getting more and more interesting, as many environment are moved to the Cloud and with the lack of direct access to the Operating System, your main way of administer your WebLogic Server environment is now via RESTFul Management Services.

For more informations on WebLogic Server RESTFul Management you may have a look on following stuff:

• Oracle Documentation for WebLogic RESTFul Management Services
• My Blog: Redeployment of versioned applications via RESTFul Management Services

Happy OTN Appreciation Day to all of you :-)

Read More

WebLogic 12.2.1 - Redeployment of versioned applications via RESTful Management Services

With the latest release of Oracle WebLogic Server 12.2.1 came quite a lot of enhancements for the RESTful Management Services. The enhancements are really impressive, you are able to monitor (GET) or to modify (POST) your WebLogic environment in detail with a simple URL call either via Browser or via Command Line Tools like cURL. The response time for such REST calls are really impressive compared to the classical way with WLST scripts :-)

For more details about RESTful Management Services you may have a look into the Official Oracle Documentation: http://docs.oracle.com/middleware/1221/wls/WLRUR/index.html

Within this post, I will show how to deploy a versioned application via a simple REST call over cURL. As base for this example you should have a look on the Oracle Learning Library Example "Oracle WebLogic Server 12c (12.2.1): Configure and Using Production Redeployment". Within this Oracle Learning Library Example you can see the classical way of deploying a versioned application. The below used versioned application is coming from this Oracle Learning Library Example, the versioned applications you can download from the before mentioned URL.

Since Oracle WebLogic Server 12.2.1 you will have a lot more possibilities within the RESTful Management Services, for example: creating Managed Servers, creating Data Sources, modifying WebLogic Server settings, deploying applications and so on.

As preparation I have downloaded the versioned.zip file from the Oracle Learning Library example, transferred it to my server on which my WebLogic Server 12.2.1 is running.

First step unzip the versioned.zip file to any directory of your server, make sure that your Oracle WebLogic Server is up and running and specially that the Managed Server to which you want to deploy the versioned application is up and running.

Second step, I simply created two shell scripts to deploy my 2 versioned applications.

Replace within the below provided script for the first deployment just the password for the weblogic user, in my case Oracle12. Align the provided deploymentPath to your path, align the provided Managed Server Name under targets and align the hostname and AdminServer port provided in the last line of the below script:

Script name: deploy_app_v1.sh

#!/bin/ksh
# Script for deployment of version 1
curl -v --user weblogic:Oracle12c \
     -H X-Requested-By:MyClient \
     -H Accept:application/json \
     -H Content-Type:application/json \
     -d "{
          name: 'simple',
          deploymentPath: '/home/oracle/versioned_app/deployversion1/simple.war',
          targets: [ManagedServer1]
         }" \
     -X POST http://wls1221:7001/management/wls/latest/deployments/application

Replace within the below provided script for the second deployment just the password for the weblogic user, in my case Oracle12. Align the provided deploymentPath to your path, align the provided Managed Server Name under targets and align the hostname and AdminServer port provided in the last line of the below script:

Script name: deploy_app_v2.sh

#!/bin/ksh
# Script for deployment of version 2
curl -v --user weblogic:Oracle12c \
     -H X-Requested-By:MyClient \
     -H Accept:application/json \
     -H Content-Type:application/json \
     -d "{
          name: 'simple',
          deploymentPath: '/home/oracle/versioned_app/deployversion2/simple.war',
          targets: [ManagedServer1]
         }" \
     -X POST http://wls1221:7001/management/wls/latest/deployments/application

Now lets start with the first deployment:

[oracle@wls1221]# ./deploy_app_v1.sh

* About to connect() to wls1221 port 7001 (#0)
*   Trying 192.168.56.10...
* Connected to wls1221 (192.168.56.10) port 7001 (#0)
* Server auth using Basic with user 'weblogic'
> POST /management/wls/latest/deployments/application HTTP/1.1
> Authorization: Basic d2VibG9naWM6T3JhY2xlMTJj
> User-Agent: curl/7.29.0
> Host: wls1221:7001
> X-Requested-By:MyClient
> Accept:application/json
> Content-Type:application/json
> Content-Length: 156
> 
* upload completely sent off: 156 out of 156 bytes
< HTTP/1.1 201 Created
< Date: Fri, 11 Dec 2015 10:37:07 GMT
< Location: http://wls1221:7001/management/wls/latest/deployments/application/id/simple
< Content-Length: 794
< Content-Type: application/json
< X-ORACLE-DMS-ECID: 0681dbbd-5c8c-47c3-bf72-2c795675d5b4-0000001a
< X-ORACLE-DMS-RID: 0
< Set-Cookie: JSESSIONID=XMaQnZ6WaiRtdYIelakH-cFG0PHNKdWdp84MMS5ryxHr1xWLUGc6!-693988513; path=/; HttpOnly
< 
{
    "item": {
        "targets": [{
            "status": "completed",
            "errors": [],
            "name": "ManagedServer1",
            "type": "server"
        }],
        "beginTime": 1449830228082,
        "endTime": 1449830234153,
        "status": "completed",
        "deploymentName": "simple",
        "description": "[Deployer:149026]deploy application simple [Version=v1] on ManagedServer1.",
        "operation": "deploy",
        "name": "ADTR-0",
        "id": "0",
        "type": "deployment"
    },
    "messages": [{
        "message": "Deployed the application 'simple'.",
        "severity": "SUCCESS"
    }],
    "links": [{
        "rel": "job",
        "uri": "http:\/\/wls1221:7001\/management\/wls\/latest\/jobs\/deployment\/id\/0"
    }]
* Connection #0 to host wls1221 left intact

Now lets open a browser and access the newly deployed application, in my case http://wls1221:7003/simple (as my target Managed Server is listening on port 7003). You should see a simple website in a blue color scheme. Type in your First Name, Last Name and Favorite Color and press "OK"

Keep the browser open and now we perform the Production Redeployment of the version 2 of our application via RESTful Management Services.

[oracle@wls1221]# ./deploy_app_v2.sh

* About to connect() to wls1221 port 7001 (#0)
*   Trying 192.168.56.10...
* Connected to wls1221 (192.168.56.10) port 7001 (#0)
* Server auth using Basic with user 'weblogic'
> POST /management/wls/latest/deployments/application HTTP/1.1
> Authorization: Basic d2VibG9naWM6T3JhY2xlMTJj
> User-Agent: curl/7.29.0
> Host: wls1221:7001
> X-Requested-By:MyClient
> Accept:application/json
> Content-Type:application/json
> Content-Length: 156
> 
* upload completely sent off: 156 out of 156 bytes
< HTTP/1.1 201 Created
< Date: Fri, 11 Dec 2015 10:37:56 GMT
< Location: http://wls1221:7001/management/wls/latest/deployments/application/id/simple
< Content-Length: 794
< Content-Type: application/json
< X-ORACLE-DMS-ECID: 0681dbbd-5c8c-47c3-bf72-2c795675d5b4-0000001c
< X-ORACLE-DMS-RID: 0
< Set-Cookie: JSESSIONID=2fCQnl74wd1Ps9WDNmfv7eTjnh3yyGnNV6eyYOnbXJHMPO1IQmDn!-693988513; path=/; HttpOnly
< 
{
    "item": {
        "targets": [{
            "status": "completed",
            "errors": [],
            "name": "ManagedServer1",
            "type": "server"
        }],
        "beginTime": 1449830276956,
        "endTime": 1449830282690,
        "status": "completed",
        "deploymentName": "simple",
        "description": "[Deployer:149026]deploy application simple [Version=v2] on ManagedServer1.",
        "operation": "deploy",
        "name": "ADTR-1",
        "id": "1",
        "type": "deployment"
    },
    "messages": [{
        "message": "Deployed the application 'simple'.",
        "severity": "SUCCESS"
    }],
    "links": [{
        "rel": "job",
        "uri": "http:\/\/wls1221:7001\/management\/wls\/latest\/jobs\/deployment\/id\/1"
    }]
* Connection #0 to host wls1221 left intact

Now open a second browser and access once again the URL of the application http://wls1221:7003/simple and now you should see a website with a green color scheme, which is the second version of the application. Type in once again your data and click "OK"

If you now go back to your first browser (with the blue color scheme), click now the link "Start over ..." and you should be able still to use the version 1 of the application as your HTTP Session object is still valid.

When we look now into the Oracle WebLogic Server Console under "Deployments" you should see the 2 versioned applications as following:

So, Production Redeployment of versioned applications via the new enhancements of the RESTful Management Services is possible and really simple.

RESTful Management is the future within Oracle Products ... see for example the latest release of Oracle Golden Gate, even within this product you have now a RESTful API connectivity for monitoring and diagnosing ... http://docs.oracle.com/goldengate/c1221/gg-winux/GRLWU/toc.htm#GRLWU102

These metrics are recorded in a RESTful API for use in diagnosing issues by Oracle GoldenGate Support and Development. These metrics can be used to improve CPU efficiency thus reducing load on source and target databases.

My advice / recommendation: have a closer look to the new enhancements of the RESTful Management Services, you have a whole new world of possibilities to refactoring your old monitoring and deployment script based on WLST, even start / shutdown / suspend / resume operations against your WebLogic Servers are possible with the new enhancements of RESTful Management Services.

Read More