1 / 37

Oracle Unified BPM Suite Development Best Practices

Oracle Unified BPM Suite Development Best Practices. Prasen Palvankar Director Product Management. Program Agenda. Best Practices for Development phase of Lifecycle Specific Design Topics Exception handling Summary. Program Agenda. Best Practices for Development phase of Lifecycle

vita
Download Presentation

Oracle Unified BPM Suite Development Best Practices

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Oracle Unified BPM Suite Development Best Practices Prasen Palvankar Director Product Management

  2. Program Agenda • Best Practices for Development phase of Lifecycle • Specific Design Topics • Exception handling • Summary

  3. Program Agenda • Best Practices for Development phase of Lifecycle • Getting Started • Managing code lines • Team development • Testing • Specific Design Topics • Exception handling • Summary

  4. Best Practices for Development phase Getting Started • Define an initial composite structure and check in to VCS • Services, Components, Business Objects, Metrics • Process structure with activities in draft mode • References should use abstract WSDLS, force use of config plan • Assign an overall owner and components owners • Overall owner manages changes to the top-level structure • Establish integration milestones and change control • Component owners check in incremental work • Top level model is refreshed and any structure changes made • Create/configure testing and continuous integration environments

  5. Best Practices for Development phase Managing Code Lines • BPM instances are bound to the composite’s version • 11.1.1.6 enables updates to an existing version without going stale • Instances can not be migrated to a newer version (planned in 11.1.1.7) VCS Version 1.0.0 VCS Version 1.0.1 VCS Version 1.0.2 Merge from 1.1 Bug Fix Composite Version 1.0 VCS Version 1.1.0 VCS Version 1.1.1 Composite Version 1.1

  6. Best Practices for Development phase • Team Development • BPMN models • should not be edited concurrently • Use sub-processes instead (reusable and standalone) • UI integration • External UI • contract is composite service interface • ADF task forms (and web form planned in 11.1.1.7) • contract is task Payload schema • Both types of UI can be developed in parallel

  7. Best Practices for Development phase • Unit Testing • Composite testing framework • Create instances • Emulate messages (wire tests) • Assert results • Rules and decisions testing • Adhoc Business Rules testing (from Studio) • No need to deploy composite to test rule • Rule and decision service can be tested • More details in session CON8606 Oracle Business Rules Use Cases, 10/3/2012, 3:30PM

  8. Best Practices for Development/Testing phase • System Testing • Integration Testing • Use SOAP message generators for synchronous testing • soapUI, XMLUnit • Develop BPM/BPEL processes as test drivers • Useful for handling asynchronous interactions • UI simulation • Ensure that any back end processing is also simulated • Active/Dynamic Stubs • Lifecycle Testing … Include scenarios for • Instance patching and new version • Backup, restore, purge

  9. Best Practices for Development/Testing phase System Testing (contd) • Load/stress test • Peak load test • Sustenance test • Failover/DR test • Continuous Integration • A CI server performs a “watchdog” role by continually watching a project and verifying that changes made to it don’t break it • On change, check project out from SCM, build it, test it • Many popular CI servers in the market place • Hudson, Cruise Control, Bamboo, Continuum • One variant of CI is nightly build/test

  10. Program Agenda • Best Practices for Development phase of Lifecycle • Specific Design Topics • Data Design • Using EDN • Multi-Instance Activity • Using the Spring Component • Human Task Integration • Exception handling • Summary

  11. Process Data Design • Loading and Storing instance state has significant performance impact • Dehydration/Hydration has to load/store all active scopes • Size of “final” state impacts the time required to purge completed instances • Amount of analytics data adds to performance considerations • Dashboard users add to overall workload on system • Key Design Considerations … • Data objects should represent the minimum set of data needed to manage the instance, reference other data via DB Adapter, or ADFbc • Define data objects in the scope where it is needed

  12. Process Data Design • SOA-INFRA Storage: • CUBE_SCOPE • Process Data Objects • WFTASK • Process Instance • Scopes for … • Parallel Gateway • Multi-Instance Activity • WFCOMMENTS • WFATTACHMENT

  13. Using EDN • EDN is surfaced in BPMN 2.0 via the Signal Event • Provides pub/sub semantics similar to JMS • Events are typed via XSD • Can be used to start, end or in-flight within a process • Benefits of Using Signals • Allows senders and receivers to be “de-coupled” • Can be used to dynamically invoke subprocesses • Considerations/Limitations • In-flight signal catch events must be correlated (no generic subscription) • Two instances can not listen for the same event • Signals can not be thrown/caught within the same process

  14. Using EDN

  15. Multi-Instance Activities Declarative Looping Within BPMN • Enables looping construct within BPMN model • Can be configured as serial or concurrent • Instance count can be defined using literal, collection size, or expression • Important Multi-Instance Design considerations • Minimize the number of instances – each is a unique scope • Each scope incurs persistence/purge overhead • Asynchronous interactions require a scoped conversation • For synchronous interactions utilize non-blocking invoke • Otherwise total time will be sum of instance execution time

  16. Multi-Instance Activities

  17. Using the Spring Component • Allows Java to be invoked from WSDL based components (e.g. BPMN) • Often used for complex calculations or procedural logic • Is an alternative to creating an “external” service (i.e. EJB or JAX-WS) • Where to put the code? Consider the scope of use … • Local use, compile source as part of the composite • Shared use, have a separate project and deploy via SOA extension library • Use the “Predefined” Spring Beans • headerHelperBean, instanceHelperBean, loggerBean • If the code authenticates to external systems • Use the OPSS Credential Mapper APIs

  18. Using The Spring Component

  19. Human Task Integration Data Design • Define interface schema first, don’t let human task dictate interface • Isolate the task form from complex external schemas • Look for opportunities to share task forms via hwtaskflow.xml • Share the definition via MDS • Minimize storage space • Store keys that reference existing data, including attachments as URLs • Minimize storage space “multipliers” • Large numbers of specific user assignments (alternative app roles, groups) • Large numbers of task data attributes (use a single complex type instead) • Loop back path(s) in process model

  20. Human Task Integration Data Design – Database Storage

  21. Human Task Integration Notifications • Disable any notifications that are not needed • Tasks have default notification for Assign, Complete, and Error • Page is rendered using org.apache.myfaces.trinidad.agent.email=true • See: http://docs.oracle.com/cd/E28271_01/web.1111/e28163/ad_output.htm#DAFFDHJE • Default task forms may not display properly in Outlook 2010 • Use conditional logic in the page to tailor the content for email • Define a router and separate page for rendering notification email • Use the drop handler to create an email optimized form • Test with all relevant email clients

  22. Human Task Integration Notifications – Creating an Email Specific Page • Use data control drop handler to create “email” page • Create router that references bpmClientType property

  23. Program Agenda • Best Practices for Development phase of Lifecycle • Specific Design Topics • Exception handling • BPMN and Policy Based • Recovery in EM and BPM Workspace • Summary

  24. Exception Handling • Exception Types • Business Exception • User defined Exception in BPMN based on business logic. • Considered as a normal part of business process. • System Exceptions • Low level errors may occur in runtime • Just like runtime exception in java. • How to Catch • Automatic • Manual • Types of BPMN Exception

  25. Exception Handling • Based on Process Model • Catch exception within process model. • Catch Business Exception. • How to catch • Error Boundary Event • Attached to any activity, subprocess • Enables user to resume main flow. • Event based Sub process. • Reuse Exception handling within process. • Automatic

  26. Exception Handling Automatic -> Process Model Event based Sub process Error Boundary Event Interrupting Boundary Error Event Non-Interrupting Boundary Timer Event Error Event Sub-process

  27. Exception Handling • Fault policy • Catch System exceptions like connection timeouts etc. • Modify without changing process model. • Engine catches exception and performance based actions • Restrictions • Valid for calling external services activities. • No support for script tasks.. • Automatic

  28. Exception Handling • How to define • Composite based <composite faultPolicy=“<name of the policy"/> • Component based <component name=“name of the component> faultPolicy=“<name of the policy"/> • Reference based <reference faultPolicy="PharosFaults"> <name>ProcedureService</name> </reference> • Automatic -> Fault Policy

  29. Exception Handling • Actions. • Retry -> Retries the instance. • Abort -> Terminates the entire instance. • Rethrow -> Rethrows the current fault. • Continue -> Ignores the fault and continues. • Ora-human-intervention -> Shows as recoverable fault in EM • Automatic -> Fault Policy

  30. Exception handling • Enterprise Manager • Fault action with ora-human-intervention. • Only Recoverable faults. • What happens if fault policy is not defined • Manual

  31. Exception handling • Workspace [Alter Flow] • Exception caused by selection failure • Selection Failure is like Null Pointer Exception. • Process instance with wrong data. • Need admin or Process Owner privileges to perform • Manual

  32. Manual Exception handling Studio Process Properties Workspace Alter Flow • Manual -> Alter Flow

  33. Program Agenda • Best Practices for Development phase of Lifecycle • Specific Design Topics • Exception handling • Summary • How design best practices help in achieving architecture qualities

  34. Summary – benefits of best practices discussed • Data Design • Better performance by optimizing dehydration/hydration and purging • Using EDN • Better reusability by decoupling • Multi-Instance Activity • Better performance by parallelism • More readable process model by hiding details under subprocess • Using the Spring Component • Better performance by minimizing external components for computations/logic implementation • More readable process model by hiding logic under beans • Human Task Integration • Better performance by optimizing payload • Better design by decoupling process from human task • Exception Handling. • Avoids any unnecessary failures • Can be recovered from process failure using Manual intervention.

More Related