Sunday Jan 18, 2015

SOA Suite 12c and the OPSS Keystore Service by Adam Desjardin

clip_image002When working with a colleague on a sample SOA 12c project recently I noticed a change in 12c that I had not seen mentioned anywhere yet.  In the sample project we were integrating with the Atlassian OnDemand service in order to provision users for Confluence and JIRA.  The integration is performed using a SOAP service over SSL.  In this situation, like at many of our customers, we needed to import additional trusted certificates into the trust store in order to make the service call over SSL.  At many of our customers this is an internal Root CA they use to sign their own certificates for internal use.

When looking at the default settings of the IntegratedServer in JDeveloper 12c we can now see below that it is configured by default to use the OPSS Keystore Service and not a JKS Trust Store.

You can see above that instead of a filesystem URI to a JKS file you now see a kss:// URI.  This URI shows that we are using the trust store called "trust" in the system strip of the Keystore Service.

The OPSS Keystore Service is meant to provide a single location for Keystores and Trust stores for all applications running within the Weblogic domain.  The only pre-requisite for using the service is that the JRF templates have been applied to your domain, which should be the case for any SOA 12c domain.

Using this service you can now manage all of your certificates through Fusion Middleware Control and WLST.  You can navigate to the Security -> Keystore menu under your domain in FMW Control as shown below. Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki

Saturday Jun 07, 2014

BPM 11g and Human Workflow Shadow Rows by Adam Desjardin

During the OFM Forum last week, there were a few discussions around the relationship between the Human Workflow (WF_TASK*) tables in the SOA_INFRA schema and BPMN processes.  It is important to know how these are related because it can have a performance impact.  We have seen this performance issue several times when BPMN processes are used to model high volume system integrations without knowing all of the implications of using BPMN in this pattern.

Most people assume that BPMN instances and their related data are stored in the CUBE_*, DLV_*, and AUDIT_* tables in the same way that BPEL instances are stored, with additional data in the BPM_* tables as well.  The group of tables that is not usually considered though is the WF* tables that are used for Human Workflow.  The WFTASK table is used by all BPMN processes in order to support features such as process level comments and attachments, whether those features are currently used in the process or not.

For a standard human task that is created from a BPMN process, the following data is stored in the WFTASK table:

  • One row per human task that is created
  • The COMPONENTTYPE = "Workflow"
  • TASKDEFINITIONID = Human Task ID (partition/CompositeName!Version/TaskName)
  • ACCESSKEY = NULL

Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki

About





Search

Archives
« August 2015
SunMonTueWedThuFriSat
      
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
     
Today