#395 Oracle ESS -> Scheduling concepts - Work Assignment, Workshift etc.

First, a simple example -

I have a job set that includes 2 jobs -

MoscowPayrollRun and
MoscowSalaryIncrease.

Then are combined in the following JobSet -

As you can see, the two jobs are defined so to run in parallel, not a good idea, if you
want your salary increase reflected in your pay.

So I define an Incompatibility -

Why Moscow? Because that's where I current am!

Scheduling with ESS

Now to some ESS concepts -

Request Processor - is mapped to a server and, as the name suggests, allocates threads for

job requests.

Work Assignment / Workshift / Schedules -

The following is copy and paste from the ESS docs -

With work allocation, you can define constraints on where and when jobs run, as well

as the amount of resources that can be used to process the jobs. This process includes

creating a work assignment and binding the work assignment to a request processor.

A work assignment consists of a specialization rule and one or more workshifts. The

specialization rule defines restrictions on which jobs can be processed. A workshift

defines the temporal windows when the jobs can be processed and what resources can

be used during those periods. The resources defined in a workshift include threads,

which are a local resource of the request processor, and asynchronous workers, a

global resource.  

How these components work with each other

Here we are talking about the items available under the menu item
Work Allocation -

The Schedule -

This can custom (e.g. one time as shown below) -

or re-occuring -

They can be also open ended i.e. no End date specified.


The Workshift -

The workshift leverages a schedule -

Note: You specify the Duration. e.g. Start every Friday at 6 pm and
run for 30 minutes.


The Work Assignment -

As you can see, A work assignment is comprised of one or more
workshifts. Specialization can be defined at this level.
i.e. what type of jobs should be executed during these assigned workshifts.

Again, from the ORCL docs -

Specialization rules: Define restrictions for job request processing on a request processor.

This combination of work assignment controls, including specialization rules and
workshifts gives you the ability to select the kinds of job requests to be processed and
decide how to allocate the request processor resources. For example, you can define
two workshifts: a day shift and a night shift to allocate processing for these periods.
The day shift could have more resources allocated for a peak usage period while the
night shift could provide a different mix for its resource allocation.
By default, no work assignments are bound to a request processor and the request
processor processes any ready job request. The default behavior is similar to using a
request processor with no specialization rules and a workshift of 24/7 duration, all
configured threads are used and there are no limits on the number of asynchronous
jobs.


You can add such specialisations, based on the following -

Afterwards, I could assign the work assignment to the Request Processor -

So that's how these things hang together!
Simple, once you know.

Test

Here is my simple example -

My Schedule is once off - starting at -

 

This schedule is leveraged by the following workshift -

The workshift is assigned to the following work assignment -

I add the Specialization -

 

I now submit a job with  SYS.PRODUCT set to PAYROLL

The job is in ready state -

Re-check, after 6:59

#394 Oracle Process Cloud Service coming soon

Check out the overview here

#393 BAM 12c Continuous Queries and Streams

First to the docs -

The Continuous Query Service (CQS) is a BAM-specific wrapper around the
Continuous Query Language (CQL) engine within the Oracle Complex Event
Processing Service Engine. The CQS is a pure push system: query results are delivered
automatically. The CQS supports both stream (non-persistent) and archived relation
(persistent) data objects.
When you create a query, the CQS sets up tables in the CQL engine, registers the
query, and listens for data changes from the persistence engine. The query result is
processed in the CQL engine, then pushed to the CQS and on to the report cache.

Now to the creation of a Continuous Query -
They act on Streams, so we have to begin by defining such a DO.

Stream DO

I will use a simple StockSale scenario here.

Here is my process -

Here are my BI settings -

I create a simple BAM dashboard to output stock symbol and price.

I output the salient data in a table -

I now create a DO of type Simple/Stream -

Note I specify one String column for the StockSymbol,
one decimal column for the stock price.

I add these via Add Column

Now, I add this new DO to my Designtime project.

Inserting Data into the Stream DO

In Designtime - I create an Alert to insert data
into the StockPriceStream1 DO - for sales over 500

Choose the option - When a data field...

I add an Action -

I do the data mapping -

I now create a high value stock sale.

I create the Stream DO Data tab

Create a Continuous Query based on the Stream DO

I want to detect duplicates on high price sales -

Note the rolling window I am using -

I will insert duplicates into a separate DO - DuplicateSales.

I realise that the above should contain custNr and orderNr but this
is just a quick demo ;--)

I add the new DO to the DesignTime project.

Now to the insert - I do this via an action, configured on the
Continuous Query -

Here is the list of available actions -

So I choose the last option - Insert values...

Map Fields -

Test by creating 2 processes for large orders with the same payload.

Here I see the  duplicate orders in the Stream,
on which the Continuous Query is based.

The duplicate has been detected and written to the
DuplicateSales DO -

#392 BAM 12c --> Data Retention, Hierarchies and Treemap views

Just some salient info on the above and other matters -

Data Retention

Click on the Administrator link and select your DO.
Click the Retention tab -

Note: Default 0 means that data will be retained indefinitely.

Hierarchies

Here is my process payload - I will create a hierarchy supplier / product.

 First I create some BI indicators in the BPEL process -

I see these in the BAM DO -

I now create a hierarchy -

I now create a Tree Query -

Add a couple of more orders for different products, from supplier Nc Inc. 

Check out the business query in BAM -

TreeMap View

In a Treemap view, hierarchical data groupings are arranged in rectangles within

rectangles. For example, our hierarchy is supplier/product. The sum of price per product

determines the size of the rectangles, and their colors.

The treemap view is based on a tree query.

So I create one based on the above -

at the bottom, one see the actual values -

Now I add a couple of orders for various products from another supplier.

As you can see, the Tree view has been updated accordingly.