#405 Excellent ICS resources for Oracle partners

Please check out the SOA Community post here

#404 BPM use of Suspend in Event Sub-processes

Here is a simple example -

The logic here is simple -
I can no longer cancel an order if the ApproveOrder4Me task has been completed.
Thus the setting of a variable in the SetNoCancelAllowed activity.

Now to the event sub-process -
Here is the configuration of the Cancel activity

It is a suspending event -
Correlation has been defined based on the orderNr.

So first I check whether it is still possible to cancel the order.
If so, all I do is log the cancellation and then exit.

If not, I set the pre-defined process variable action to resume (note: lower case)

So now to the test -

I start an order process -

The process is waiting at the first human task, so I can still cancel.

I cancel -

I should see 2 instances of the composite in em -

I click on the first instance (430023)

I now test resumption after suspension -

I create a new order process instance -

I go to the first human task and APPROVE -

From a functional perspective, I should no longer be able to cancel,
The first human task has been executed and the process is now waiting at the 2nd.

But I try it anyway -

Now don't get confused by the human task name, I am reusing the same
human task for both activities.

I now go back to workspace and approve the second task -

I check the audit trail in em -

#403 BPM Throw Terminate - at your own risk!

Simple example -

This process is called from my order process, used in the previous post -
Note CallTerminator etc -

I deploy and test with OrderNr 123 -

So let's look at the audit trail for OrderProcess

However, according to em, the process is still running -

Not what was probably wanted!
Terminate should also not be used in parallel or inclusive gateways.

#402 BPM - Reusable Processes

So what are reusable processes in BPM?
reusable, you may say and who am I to disagree!

But there must be something more to it, right?

Let's begin with the ORCL docs -

You can invoke a process from another process using call activities. The invoked
process is a child of the process invoking it.
When you run a call activity, the engine does not create a new token for the reusable
process. The token in the parent process passes to the reusable process. When the
token completes the child process, it returns to the parent process to continue running
the activities that follow the call activity.
The child process must be a reusable process. Reusable processes can be invoked from
multiple processes. You can only start a reusable process by invoking it from a call
activity.
You cannot access reusable process from other SOA components because they are not
part of the SOA composite.
The start event of a reusable process must always be of type none. The end event can
be a error or a message event.

Here is a simple composite containing a BPM process -

As usual with my examples, it is an order process.
Sure where would we be without such?

Anyway, now I add a new BPM Process, of type
Reusable Process,  to the composite -

Input/Output as follows -

Note - you do not see the reusable process in the composite view -

Edit the Security Process and add a Human Task -

Now call this reusable process from the main order process -

Do the Data Associations, for input and output -

Some takeaways at this stage -

1. The reusable sub process does not have OOTB access to it's calling or parent process variables.
It only can see those passed as arguments. In the above case, the

2. These are not defined at the Start / End nodes of the sub-process, as you may have expected.

3. Reusable sub-processes are not exposed to the outside world. They can only be used
within composite boundaries.

Now let's deploy and test.

I approve the order -

Check out the em audit trail -

Now, I create a another BPM process -

I call it from the order process, as follows -

I deploy and test - here we see, of course, the 2 process instances

Another takeaway - the reusable sub-process runs within the "parent" process instance.
Calling another process via Send/Receive will cause separate instances to be created.

#401 API Manager basics

Introduction

A short introduction to the product -

post #378 described how to install, let's now look at what we get.

To quote the ORCL docs -

Oracle API Manager facilitates the creation of APIs that expose functionality of
backend systems or other services. These APIs are published for use by application
developers and are managed and monitored at runtime.
API Manager is built on Oracle Service Bus. Proxy services created using Service Bus
can be published as APIs. API Curators decide which of these services should be
managed and exposed to developers. API Curators then add metadata and publish the
APIs to a developer portal, from which application developers subscribe to and view
information necessary to consume the APIs. Administrative users can use the
developer portal to monitor usage metrics and performance analytics at runtime.

Now to the roles -

API Curator: Users with this role use the Service Bus Console to curate the
metadata associated with and expose proxy services as APIs through the API
Manager Developer Portal. Users assigned this role have read-only access to the
remainder of the Service Bus Console so they can view artifact information.

API Consumer: Users with this role can use the API Manager Developer Portal to
view, subscribe to, and consume APIs. Users assigned this role have no access to
the Service Bus Console.

API Admin: Users with this role have administrative privileges for the API
Manager Developer Portal. API Admin users can view API usage metrics,
analytics information, and detailed subscription information for each User and
API. Users assigned this role have no access to the Service Bus Console.

Now that we have the general idea of what API Manager is, let's take a look at the components -

I will begin with em - because this is where you create the api manager users.

Create API Manager users in EM

Here are the roles -

Assign our new consumer user to this role -

Assign our new mgr user to this role -

API Manager Portal

http://localhost:7001/apimanager

login as MyAPIConsumer/welcome1

Note the 3 tabs on the right -

Logout and login as MyAPIManager/welcome1

Service Bus Console

Here I have a simple SB pipeline that routes a request to a simple credit card

validation service I created.

I edit the API values -

Once published, we can see it in the portal -

Managed/ Un-managed?

So what does this checkbox mean?

Back to the ORCL docs for an explanation -

A managed API is an access-controlled API. Per-user metrics are also available for

managed APIs. In order to successfully invoke a managed API, a user will first need to 

create an application and subscribe to a given managed API. 

The client must then invoke the API providing the API Key for the call to be successful.

Unmanaged APis can be invoked without subscription and without passing an

entitlement key at runtime.

API Subscription

Back in the portal as the consumer user -

The consumer subscribes to APIs via an Application.

Select the API -

Note the key - 9b0d5689-30b0-4b1f-bda7-09b3625348b1