#507 Java API for ICS --> A-Team blog post

Check it out here

#506 SOA 12.2.2.1. --> JSON processing in BPEL

An excellent feature...

Here is a simple example in which I process a customer.

I start by creating a REST interface -

Now I create the BPEL process, based on this -

Edit the process -

Let's look at the process variables -

Now, if I want to address these within the process, I need to do so as -
process.inputVar.parameterName

e.g. process.inputVar.custName.

I can leverage the above in a simple assign as follows -

Note: I do not see any input structure in the ASSIGN activity.

So I need to add a suffix to outputVar.

Edit the above assignment - adding an attribute to the outputVar.

I deploy and test -

Now I add a JavaScript activity to the BPEL process -

Here I am referring to a new process variable v_response.
I need to define this.

Now let's use v_response to set the output.

Re-deploy and Re-test -

What if this BPEL process needs to call another process, for example, to validate the
customer?

Validate Customer is a simple process -

So how do I pass the JSON input to this process?

Again, edit the ASSIGN -

Simple stuff!

#505 ICS --> message sizes etc.

A question that often arises -

How big can the messages be that pass thru ICS, and how many messages can I have per connection?

Simple answer -

go to the Integration CS pricing page here

and read -

This Oracle Cloud Service requires at minimum six (6) Connections per month. 

maximum usage of up to one hundred thousand (100,000) messages per connection per day. 

The size of the message may not exceed 512 KB.

Now things changed somewhat with the release of 16.2.1.

The What's New? doc  available here contains the following -

Message payloads of up to 10 MB can be exchanged between source and target endpoints in integrations. For integrations involving the connectivity on-premises agent, message payloads of up to 5 MB are supported.

#504 JCS / DB CS --> Lifting and shifting a web app from on-prem to Oracle PaaS

A short post to show how easy it is to lift and shift a web app from on-prem to the Oracle Cloud.

My on-prem app is very basic, simply a servlet that calls my local Oracle DB.
The servlet calls a helper class, CallDB().
Here is an extract from that class.
As you can see, I have hard coded the connect info -

connection = DriverManager.getConnection("
jdbc:oracle:thin:@localhost:1521:xe", "system", "welcome1");

 

Here is an extract from the servlet - As you can see, I am simply executing

SELECT TO_CHAR(SYSDATE) FROM DUAL;

I run this from JDeveloper, the servlet is deployed to the integrated weblogic server.

Now how do I lift and shift this to JCS and DB CS?

Very easy -

Step 1 - Amend the connect string in the helper class to point to my DBCS environment.
Here is the format of the connect string -

 connection = DriverManager.getConnection("
jdbc:oracle:thin:@YourMachine:1521/YourDB", "YourDBUser", "YourPwd");

So how did I get the connect string for my DB CS instance?

I worked the above out by looking at one of the datasources
already defined in my JCS instance, and just extrapolated from that.

Just take the URL from above.

So that's it!

You can, of course, validate the string by sshing into the DB CS VM.

Then go to the /network/admin directory and check tnsnames.ora.

Step 2 - Package up the web app as a WAR file.

Step 3 - Deploy the WAR file via the JCS WLS console - just
select option from the hamburger menu.

As you can see, I have already deployed my SimpleJDBCDemo app.

I have deployed to the admin server and manager server on JCS.

Step 4. Test using the public ip address of the JCS VM.

We can check the weblogic log files for the output messages from CallDB()
ssh into the WLS vm.

sudo su -oracle

Navigate down the WLS directory structure -

tail -f NCJCS_do_adminserver.out

Re-execute the servlet - and view the messages in the .out file -

Great stuff!

#503 IaaS --> Storage Cloud Service REST API

Simple example -

Create a container -

Again, we begin by authenticating.
The request has the following format -

curl -v -s -X GET -H "X-Storage-User: Storage-YourIdentityDomain:
YourUser" -H "X-Storage-Pass: YourPwd"
https://YourIdentityDomain.storage.oraclecloud.com/auth/v1.0

I now use X-Auth-Token and X-Storage-URL in subsequent request(s).

curl -v -s -X PUT -H "X-Auth-Token: YourAuthToken"
https://YourStorageUrl/v1/Storage-YourIdentityDomain/NiallC_images

NiallC-images is my Container name

Use the following REST request to validate creation -

#502 IaaS --> Compute Service REST API via Postman

So again, I first need to authenticate, before I can execute any REST requests of import.



curl -i -X POST -H "Content-Type: application/oracle-compute-v3+json" -d '{"user":"/Compute-YourIdentityDomain/YourUser","password":"YourPwd"}' https://YourRESTEndpoint/authenticate/

Here is the request/response in Postman -

We are interested in the X-Oracle-Compute-Call-Id

X-Oracle-Compute-Call-Id →1605106c8e1eb8d2129191bd53539248a18d0b


Now I use this in the subsequent request(s)

Here I list the Instances -

https://YourRESTEndpoint/instance/Compute-YourIdentityDomain/YourUser/

Get the image list - this will return the image I cloned in a previous post.


https://YourRESTEndpoint/imagelist/Compute-YourIdentityDomain/YourUser/

Get the list of shapes - note the format of this request -

https://YourRESTEndpoint/shape/