Wednesday, October 16, 2013

Getting Started with Continuous Integration for Oracle Fusion Middleware

Getting Started with Continuous Integration for Oracle Fusion Middleware
These articles are to help you get started… they are not necessarily meant to show the best practices – see below for some comments on that.
§  Hudson is a common Continuous Integration server which you can run standalone, or if you prefer, you can run it on WebLogic Server.  Installing Hudson on WebLogic Servershows you how.
§  Deploying WebLogic applications with Maven shows you how to use the new WebLogic Maven Plugin to deploy applications to your WebLogic Server environment using Maven.
§  Getting started with continuous integration for SOA projects explains how to set up some basic continuous integration capabilities using Hudson, Maven and Subversion with JDeveloper.
§  Extending our continuous integration approach to work with MDS-dependent components explores how we can configure our CI build to work when some components in the composite require MDS.  Adding Human Tasks or Rules to a composite, for example, will add a dependency on MDS.
§  Adding SCA Tests shows you how to include SCA Test execution in our CI Build.  This includes seeing the results in the Hudson console.
§  Deploying Canonical Data to MDS (coming soon) shows how to deploy your canonical data model to Metadata Services using Hudson.
§  Extending our sample to include BPEL, BPMN, Rules, Spring, Web Services and Human Tasks (coming soon) provides access to a sample that you can download and experiment with in your own environment.
§  Using Continuous Integration for a whole SOA Application (coming soon), i.e. a composite, user interface(s) for the human tasks, and canonical data; including SCA Test and SOA Configuration Plans (for targeting different environments).
§  Getting started with Continuous Integration for Oracle Service Bus shows the basics of how to script a build and deployment for OSB
§  Building OSB projects with Maven and removing the eclipse dependency takes this a step further to use the new configjar tool introduced in OSB PS6 and execute the build in Maven


Tuesday, October 15, 2013

Choosing BPMN or BPEL to model your processes from Redstack

  • Write top level (i.e. true ‘business’ processes) in BPMN,
  • Do not perform any kind of system interaction in these processes – don’t use adapters, call web services, etc.,
  • Use activities or embedded sub-processes with boundary events and event sub-processes to handle all business faults that may occur,
  • Make sure to have a ‘catch all’ event sub-process to handle any failures that are not specifically handled,
  • Theoretically there should never be a system fault in these BPMN processes,
  • Whenever there is a need to do some actual work, delegate this to BPEL, i.e. use a service activity with implementation type ‘service call’ to have BPEL go do the work,
  • Make the BPEL processes atomic, so that they can easily be retried, rolled back, etc.,
  • Use the fault management framework to control the handling of faults in the BPEL processes, and
  • Keep BPEL ‘worker’ processes in separate composites from BPMN ‘business’ processes.