Oracle SOA Suite Tips and Tricks from Oracle …...Oracle SOA Suite Tips and Tricks from Oracle...

89

Transcript of Oracle SOA Suite Tips and Tricks from Oracle …...Oracle SOA Suite Tips and Tricks from Oracle...

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Oracle SOA Suite Tips and Tricks from Oracle Engineering

Deepak Arora, Oracle A-team

Sherwood Zern, Oracle A-team

Yogesh Kumar, Oracle SOA Suite Engineering

Simone Geib, Oracle SOA Suite Product Management, [email protected]

David Shaffer, Middleworks, [email protected]

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Safe Harbor Statement

The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

3

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Goals of Session

• SOA Engineering/A-team get pulled into many customer escalations

• Want to proactively share knowledge learned helping customers

• Promote active discussion and Q&A!

• Much more content in slides than we will cover here – please peruse at your leisure…

• Also see:www.oracle.com/technetwork/middleware/soasuite/learnmore/default-427190.html

• Give us a business card or email [email protected] if you are interested in a follow-on webinar and other related content

4

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

SOA lifecycle check lists

Deepak AroraDirectorOracle A-TeamSeptember 30, 2014

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Program Agenda

SOA lifecycle stages and check lists

Development and functional sign off

Unit and integration testing

Performance testing

Deployment topology

High availability and resiliency check

Operational readiness

1

2

3

4

5

6

7

7

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Program Agenda

SOA lifecycle stages and check lists

Development and functional sign off

Unit and integration testing

Performance testing

Deployment topology

High availability and resiliency check

Operational readiness

1

2

3

4

5

6

7

8

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

SOA lifecycle stages and check listsHow to prepare

• Development and functional sign off

• Unit and integration testing

• Performance testing

• Deployment topology

• High availability and resiliency check

• Operational readiness

9

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Program Agenda

SOA lifecycle stages and check lists

Development and functional sign off

Unit and integration testing

Performance testing

Deployment topology

High availability and resiliency check

Operational readiness

1

2

3

4

5

6

7

10

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

SOA lifecycle check list – contd.Development and functional sign off

11

• Complete business and design walk through

• Define business transactions and create a break down of atomic business vis-à-vis technical transactions.

• Define number of batch vs. online transactions

• Define a general guide book of integration patterns mapped to transport protocols

• Map what technologies will be used in above use cases (for e.g. OSB, SOA Suite, BPMN etc)

• Chart out technical components with functional designs using swim lanes with role definitions

• Define data models to be used for solution

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

SOA lifecycle check list – contd.Development and functional sign off

• Define integration, error handling, audit, fault management, retry and compensation handling patterns – more concrete view of the solution. (Try to leverage AIA development framework and practices)

• Define continuous integration practices and tool sets

• Beware of development anti-patterns

• Stick to the rule of thumb 70% synchronous and 30% asynchronous services

• Understand access and security model for services being developed (API management)

• Develop!

12

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Program Agenda

SOA lifecycle stages and check lists

Development and functional sign off

Unit and integration testing

Performance testing

Deployment topology

High availability and resiliency check

Operational readiness

1

2

3

4

5

6

7

13

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

SOA lifecycle check list – contd.Unit and integration testing

• Define use cases for composite unit testing

• Define integration use cases for functional sign off (positive and negative)

• Complete set up of test environment with queues, data types, integration stubs and end points and other 3rd party applications

• Set up negative integration testing, validating atomicity of business transactions, compensation scenarios(if any), retry scenarios, and error handling scenarios

• Collect real data to facilitate testing

• Continuous integration best practices to include, compile, build, versioning, creation of assets (using deployment plans), regression testing and deployment

14

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

SOA lifecycle check list – contd.Unit and integration testing

15

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Program Agenda

SOA lifecycle stages and check lists

Development and functional sign off

Unit and integration testing

Performance testing

Deployment topology

High availability and resiliency check

Operational readiness

1

2

3

4

5

6

7

16

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

SOA lifecycle check list – contd.Performance testing

• Define performance testing strategy. Strategy should include:

– SLA’s and metrics that are important to the business

– Tools to gather metrics and develop analytical framework, toolsets and reporting structures

– Performance testing methodology to attain SLA’s (load bursts, peak performance, load sustenance over a short and long period)

– Performance testing scenarios and toolsets to generate load.

– Define different message payload structures and sizes to stress the system

– Iterative testing starting with 1 SOA Managed Server and extending to a SOA Cluster while maintaining a complete log of changed parameters

17

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

SOA lifecycle check list – contd.Performance testing

• Define deployment unit for e.g. OVM running OEL with 8vCPU with 32 GB of RAM. Each OVM will run a single SOA Managed Server

• Define breaking point for single deployment unit – usually CPU usage for e.g. 70% CPU utilization

• Ensure there are no functional exceptions

• Perform iterative testing, tuning JVM, GC, Threads, and DB!!

• Performance testing team should contain of SOA Administrators, SOA developers and a well qualified DBA

• Conduct test on cluster adding deployment units till desired performance is achieved

• Conduct purge performance testing – will define final purge strategy

18

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Program Agenda

SOA lifecycle stages and check lists

Development and functional sign off

Unit and integration testing

Performance testing

Deployment topology

High availability and resiliency check

Operational readiness

1

2

3

4

5

6

7

19

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

SOA lifecycle check list – contd.Deployment topology

• Define production topology – final topology can differ from reference topology based on the following criteria:

– Batch vs real time domain – pure performance criteria

– Business domain segregation due to functional complexity, proneness to constant code changes, uptime requirements or mission criticalness of solution

• Define final purge strategy for SOA DB – will define how the schemas are set up

• Create SOA cluster based on best practices. Things missed are:

– Front end host and URL set up

– Not using Active Grid Link

– Poor start up and shut down practices

– Not setting up UDQ on cluster set up

20

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Program Agenda

SOA lifecycle stages and check lists

Development and functional sign off

Unit and integration testing

Performance testing

Deployment topology

High availability and resiliency check

Operational readiness

1

2

3

4

5

6

7

21

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

SOA lifecycle check list – contd.High availability and resiliency check

• Define HA tests to:

– Check for server restarts (nodemanager restart)

– Check for process continuation in asynchronous situations in failover scenarios

– Whole server migration testing (if configured) or VM move testing

– Data center migration (if configured) in disaster recovery scenarios

22

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Program Agenda

SOA lifecycle stages and check lists

Development and functional sign off

Unit and integration testing

Performance testing

Deployment topology

High availability and resiliency check

Operational readiness

1

2

3

4

5

6

7

23

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

SOA lifecycle check list – contd.Operational readiness

• Define standard operating procedures for:

– Start and shut down

– JMS message throttling (if required)

– Confirmation that servers have started correctly before sending in messages

– Log collections - .out, .diagnostic.log, .error, etc

– JMS Queue flushing (if required)

• Classify list of exceptions into 2 buckets a) ones that can be ignored and b) that need actions

• Define error handling and recovery procedures for message resubmission from EM console or otherwise

• Provide procedures on how to troubleshoot when diagnosed with issues and errors

24

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

SOA lifecycle check list – contd.Operational readiness

• Team composition should include a full time DBA in the SOA operational team

• Purge based on purge strategy

• Rebuild DB indexes on a timely basis to maintain performance metrics

• Conduct constant DB backups in case of failures

25

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Oracle Service Bus Tips

Sherwood ZernConsulting Solution ArchitectOracle A-TeamSeptember 30, 2014

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Agenda

Production Readiness

Transactions and Quality Of Service

Miscellaneous

1

2

3

28

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Agenda

Production Readiness

Transactions and Quality of Service

Miscellaneous

1

2

3

29

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Production Readiness• Make sure thorough end-to-end testing has been done

– Test with data that resembles production data early in the development and testing cycle

– Execute tests against one managed server to know how much load one server can support and still meet the defined SLAs

• This will help in determining the overall number of managed servers required

• Scale out based upon this test

– Services that are deemed reusable should be tested against all known client types and channels

– Do not skimp on the performance testing

• The performance environment should match the production environment

30

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Production Readiness• Make sure thorough end-to-end testing has been done

– Run plenty of negative tests

• Will prove whether or not transactions are rolled back

– If the transactions are not rolled back as expected then have potential of message loss or data being out of sync

• Know whether downstream systems will have negative impact on the OSB if the remote system is down

– A prime example is JMS queues can fill up and eventually cause out-of-memory errors

– Requests back up in the OSB due to slow responses from remote systems

31

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Production Readiness• Require clearly defined Service-Level Agreements

– Service Level Agreements must be set against the following:

• Availability

• Throughput

• Concurrency

• Response Time

– Performance testing cannot be completed and validated without SLAs

– Each service must have a SLA

– Connect and read timeouts must be set to ensure compliance with the SLA

32

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Production Readiness

• Use Work Managers

– Minimum constraint work manager when using service callouts

• Guarantees there will always be one thread available to handle the response

– Fair-Share if want to ensure some services are given a higher priority over other services

– Use a maximum thread constraint to restrict how many threads can be used by a specific service

33

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Production Readiness

• Understand the capacity of the downstream systems

– Think of the OSB as the dam that controls the flow

– Assign a maximum thread constraint work manager on the proxy service and set the quality of service set to “Exactly-Once” to throttle requests to business services

– For business service throttling, set the service concurrency to control the domain-wide concurrency

34

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Production Readiness

• Design and implement a common error handling framework

– SOA with Foundation Pack has a nice error handling framework

– Too many customers wait until the last minute to implement the error handling

• Leads to a lot of redundant “code” amongst the message flows

• Error handling is convoluted and difficult to understand

• Consider leveraging Result Cache

– If concerned with the amount of data being cached then consider an out-of-process cache

– The use of a Java callout can also be an approach to leveraging a cache

35

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Production Readiness

• Increase the router runtime cache (Note: not the same as result cache)

– Defaults to 100

– Proxy services are “compiled” and cached upon the first request

– Consider increasing the runtime cache size based upon the number of proxy services

– Depending upon the resulting runtime cache size it may be necessary to increase the heap size.

36

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Production Readiness

• Reconsider that decision to have only one OSB domain to handle both batch and online requests

– How often are the batch jobs executed?

– What is the size of the batches?

– When are the batch jobs executed; during online hours?

– Is there a way to determine a batch request versus an online request?

• Want to ensure that online requests get higher priority than a batch request

37

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Agenda

Production Readiness

Transactions and Quality of Service

Miscellaneous

1

2

3

38

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Transactions and Quality of Service• Know the transaction demarcation

– http://atheek.wordpress.com/2011/04/21/transaction-handling-within-osb/

• When using JMS protocol and referencing a remote connection factory make sure to enable “Is XA Required” in the advanced settings

– This will ensure that the generated mdb will have the transaction attribute set properly

• Verify that the quality of service is correctly set and understand what impact it will have on the service from a global and local transaction perspective

39

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Transactions and Quality of Service

• Key points to make note of:

– HTTP transport does not support XA and cannot be part of the global transaction

– An inbound transactional transport, such as JMS, proxy service will change QoS to Exactly-Once

– A JMS destination not participating in the global transaction may have unintended consequences of duplicate messages being delivered if there is a rollback and retries

• As an example, setting the QoS to Best-Effort in the routing options will force the business service to commit in a local transaction and therefore will not be part of the global transaction

– Make sure a limit is specified on the number of retries ( > -1)

• Not doing so will continue to resubmit the message indefinitely

40

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Program Agenda

Threads and Work Managers

Transactions and Quality of Service

Miscellaneous

1

3

2

41

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Threads and Work ManagersServer Architecture

42

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Threads And Work Managers

• Waits for connection requests, accepts the request, hands the socket off to the muxer, and goes back to wait for the next request

• By default, WLS listens on two ports

– Listen Port – All non-SSL based protocols (T3, HTTP, IIOP, etc)

– SSL Listen Port – All SSL-based protocols (T3S, HTTPS, IIOPS, etc_

• May also configure additional network channels to allow additional ports to be defined and limit the protocols accepted

Listen Ports and Listen Threads

43

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Threads And Work Managers

• Detects incoming requests on established connections

• Handles requests for any supported protocol

• Inspects first few bytes of input stream to:

– Determine the protocol

– Determine the request target

– Determines the work manager

• Packages the request up and puts it on the execute queue

Socket Muxer Overview

44

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

OSB Thread Usage

• Default Thread Model

– Incoming requests are given an execute thread

• As soon as a route to a business service happens then the incoming thread is returned to the thread pool

– The response will be handled on a different thread

45

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

OSB Thread Usage• Exceptions to this pattern

– Service Callouts

• Will block the request thread until a response is received

• The response will be returned on a separate thread

• Assign a minimum constraint work manager to the invoked service to prevent the possibility of encountering stuck threads

• This is one of the biggest issues seen in the field today

46

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

OSB Thread Usage

• Exceptions to this pattern

– Java Callouts

• The invocation to the operation is executed on the request thread

• The response will be returned on the calling thread

• Invoking an operation to remote services is not advised

47

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

OSB Thread Usage

• Exceptions to this pattern

– Changing the Quality of Service to Exactly-Once

• The requesting thread is blocked until a response is received.

• The response will still be handled on a separate thread

48

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Work Managers

• Assign a minimum constraint work manager to services invoked by a service callout

• Advisable not to use the same work manager for both the proxy service and business service

• A work manager assigned to a business service comes into play on the response pipeline

• Work managers are per JVM

49

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Transactions and Quality of ServiceMessages Lost

• Scenario

– Configured a non-XA connection factory

– Message was posted to Queue and was consumed by an inbound JMS proxy service

– Error is encountered during the processing of the message flow

• Result

– The message will be lost unless exception handler is provided to repost the message

50

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Transactions and Quality of ServiceMessages Lost - Corrected

• Scenario

– Configured a XA connection factory for Proxy Service and Business Service

– Message was posted to Queue and then consumed by an inbound JMS proxy service

– Error is encountered on the response pipeline of the message flow

• Result

– The message will be rolled back to the original queue. No messages are lost.

51

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Transactions and Quality of ServiceErrors Result In Duplicate Messages

• Scenario

– Configured an XA connection factory for Proxy Service and Business Service

– Changed the Quality of Service of the business service to Best-Effort

52

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Transactions and Quality of ServiceErrors Result in Duplicate Messages

– Message was posted to Queue and then consumed by an inbound JMS proxy service

– Error was encountered on the response pipeline of the message flow

• Result

– No messages will be lost, but there will be “number of retries + 1” messages sitting on the business service queue

– Why?

• The Best-Effort forced the business service to a local transaction; therefore, its commit was outside of the global transaction

53

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Miscellaneous

• Only use SOA-Direct binding if transaction propagation or security context propagation is required

• JMS advanced settings within the OSB will override the settings specified on the queue in WLS

• The OSB implements a co-location optimization for the transports, HTTP, FTP, e-mail, File, JCA, SB, SFTP, and Tuxedo

• Publish Action to any transport that supports the co-location optimization, including local, will continue to use the same thread; therefore, it is not fire-and-forget

• When using an inbound JMS proxy service and the UDQ is within the same OSB domain there is no need to specify the host and port. (jms:///theConnectionFactory/theQueue)

54

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Miscellaneous • When specifying JMS business service existing URI the OSB behavior is

different between specifying the items on an individual line or comma separated

– Individual endpoints listed

• With each endpoint individually listed the OSB will round-robin between them.

• If the URI selected is not available then the OSB will go to the next endpoint in the list

• The retry will only come into play once the list has been completely traversed and the OSB was unable to connect to one of the endpoints.

55

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Miscellaneous • When specifying JMS business service existing URI the OSB behavior is

different between specifying the items on an individual line or comma separated

– Comma-Separated List

• The OSB sees the list as only one URI; therefore, there is no round-robin per-se

• The OSB will attempt to connect to the first URI

• If the attempt was unsuccessful then the OSB will wait the retry interval and go to the next <host>:<port> specified

56

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

SOA Development Best Practices

Yogesh KumarDirector, Software DevelopmentSOA Core and BPEL DevelopmentSeptember, 2014

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Background

• Sadly, customers don’t call into engineering to say “I just built this app and

it all works great! Thanks for your service!” ☺

• We help people recover from (or better yet, avoid) precarious situations

59

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Program Agenda

Reducing your code

SOA Anti-patterns

1

2

60

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Reducing your codeThe best code you will ever write is… code you never write.

61

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

BPEL Code

• Increase in number of BPEL activities will have an impact on performance,

scalability, monitor ability, manageability

• Replicating code, error handling, etc increases code and makes

maintenance more difficult

• More instructions means more code to debug and maintain

• Recommendations

– Reduce code by using declarative constructs

– Eliminate redundant code by code re-use vs copy+pasting code fragments

62

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Use declarative assertion conditions to throw faults

• Use preAssert, postAssert to throw faults prior to sending outbound or upon receiving inbound messages

– Assertion condition is executed upon receipt of a callback / inbound message or prior to sending an outbound message

– If XPath expression is evaluated to false, BPEL fault will be thrown from the activity

• Pre Assert: Condition is executed before the invoke or reply activity sends out the outbound message

• Post Assert: Condition is executed after an invoke activity, receive activity, or onMessage branch receives the inbound message

Oracle Confidential – Subject to change - intended for information purposes only, and may not be incorporated into any contract. 63

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Throwing faults with assertion conditions (cont’d)• Use declarative Construct: assert activity

– This is a standalone activity in which to specify assertions.

– If XPath expression is evaluated to false, BPEL fault will be thrown from the activity

• Pre Assert: Condition is executed before the invoke or reply activity sends out the outbound message

• Post Assert: Condition is executed after an invoke activity, receive activity, or onMessage branch receives the inbound message

64

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Need to perform an activity only under certain conditions?

• Use declarative construct: Skip Condition

– Skip an activity if an XPath expression evaluates to true

– Provides an alternative to using a switch activity for conditionally executing activities

– Equivalent to switch / case structured activity

– Skip Condition feature is available for most of the BPEL activities

65

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Use declarative Timeouts

– Alternative to onMessage and onAlarm branches of a pick activity to specify timeouts

– Provides a timeout setting for receive activity

– Alternative to using the onMessage and onAlarm branches of a pick activity to specify a timeout duration for partner callbacks.

66

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Reusable Error Handling•Use feature : Fault Policy

•Use for error handling that is external to SOAand does not impact the SOA/BPEL design or runtime

•Policies are defined in XML

•Policies are re useable across composites and components

•Defines actions that can be used for the SOA instance

•retry, human intervention, replay scope, rethrow fault, abort, and custom Java actions

67

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

12c Feature - SOA ‘Starter’ Templates

• ‘Starter’ Template is a re-usable part of a SOA project

• Fully editable• Stored in MDS• Three types:

� SOA Project Template�Component Template�Custom Activity Template

Re-use at all levels

Component

BPEL activity

How to create a template?

Project

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

12c Feature - SOA ‘Starter’ Templates

• Project template accessible at the time of new project creation

• Automatically discover in the component palette – Component Template– Custom Activity Template

• Share and re-use from MDS

Re-use at all levels

Project

How to consume a template?

Component

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

12c Feature- BPEL Sub-processes: standalone and inline

• Allows business logic to be modularized and reused• Permits access of data in parent process• Improves performance and manageability• Compensation and fault handling inherited from calling

process• Faster rendering as only the entity in question is

rendered

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

SOA Anti-patternsDesign it Right

71

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Over usage of Asynchronous processes

• Over usage of asynchronous processes (Mediator/BPEL, Mediator with asynchronous routing rules)

– Adds dehydration overhead

– Developers are not aware of transactional boundaries which can quickly complicate the message lifecycle

• Over usage of callbacks (chatty system) in a single BPEL process

– Every callback is a dehydration point which will cause DB activity

– Having too many callback activities can quickly impact performance

72

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

• Using a large while loop to implement retry logics, or even a daemon process comes with

the following problems:

– Each loop iteration creates a new scope object. This object takes memory, not much but with each

iteration the total allocated space grows (1+2+3+4 …)

– If a large while loop contains a breakpoint activity such as Wait, the entire scope tree will need to be

persisted as well as any work items created since the last dehydration.

– Using very big loops to conduct iterative processing – does not scale with large numbers

– Can lead to big JVM object heaps and potential GC bottlenecks

• Recommendations

– Use BPEL as a glue to orchestrate service endpoints instead as a programming language

– 10’s of iterations are probably fine. 100’s or 1000’s are probably not…

• Similar anti-pattern with FlowN…

Large while loops in BPEL processes

73

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Mis-use of FlowN for processing a large data set

• Common [Mis-]Use Cases

• Send email notification to all whose purchase orders are delinquent

• Do processing for each of the order lines found in an order document

• Do user provisioning for all employees present in a batch

• Impacts

• Need to be conscious of the load being put on down stream systems

• Invocation of asynchronous BPEL process in a while loop having large number of iterations could result in denial

of resources for co-located composite applications

Recommendations

• Do not have the data set dictate the value for N

• N should be configurable

• Should provide the ability for administrators to throttle the value for N depending upon resource / memory constraints

74

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Anti-pattern: Overuse of Asychronous Processes / Interfaces

BPEL Process A

BPEL Process B BPEL Process C

• Asynchronous interaction :

– Each asynchronous invocation will result in a request being

persisted in dB

– Invoker resource needs to be allocated for processing the

request

– Asynchronous response from callee will again be persisted

– Delivery resource needs to be allocated for callback processing

• Recommendations

– Model the callee bpel process as synchronous one and

participate in parent transaction provided there are no

breakpoint activities

– Have asynchronous callee bpel process be invoked on parent’s

thread

75

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

dlv_messagecube_instance,

audit_trail

Adapter

JMS

Anti-Pattern – Design of ApplicationsBPEL Design Considerations – Inbound Adapter with Async Process

76

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

• The inbound backend system is a natural persistence of the message

• Asynch BPEL’s also persists the message

• Persisting the data at two places do not necessarily make the BPEL

process more reliable

• Recommendations:

– When no obvious benefits,

– set oneWayDeliveryPolicy to sync

– or make the process synchronous

Anti-Pattern – Design of ApplicationsBPEL Design Considerations – Inbound Adapter with Async Process

77

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

cube_instance,

audit_trail

Adapter

JMS

oneWayDeliveryPolicy=sync

Anti-Pattern – Design of ApplicationsBPEL Design Considerations – Inbound Adapter with Async Process

78

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

• Successfully completed transient BPEL processes should not be persisted

• Only faulted instances for transient services should be persisted

• AuditLevel to off at Service Component level

• Setting the following component parameters will persist only faulted

instances

<configurations>

<property name="inMemoryOptimization">true</property>

<property name="completionPersistPolicy">faulted</property>

<property name=“bpel.config.auditLevel">off</property>

</configurations>

Anti-Pattern – Persisting synchronous transient processesDisable the audit for transient services

79

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Anti-pattern: Unlimited Storage ?

• Do you have unlimited storage – probably not

• Audit Trail accounts for a large percentage of the data persisted

– Use audit levels wisely

– 12.1.3 allows for audit control at BPEL activity level, limit audit to critical activities

• Global variables in BPEL causes persistence on every dehydration

– Use local variable

• Purge

– Identify storage requirements and continuously purge closed instance.

– 12.1.3 comes with out of box auto purge

• Review workload

– Do you have partners sending callback even when instance is not expecting?

80

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

• Keep service hops to a minimum

• Local optimization will occur only if the caller and callee are collocated

• Strike the right balance between loose coupling and performance

• Need to think about the transaction scope / atomicity

• Do you want callee to enlist itself in caller transaction

• Think about the latency of the transaction

• Too many hops also lead to out of sequence messaging

Anti-pattern: Over Engineered End-to-End SOA Flows

DB Adapter

SOURCE

JCA Adapter

TARGET

Consumer Enrichment Transformation

Sa

les

Ord

er

EB

S

Sa

les

Ord

er

EB

S

Orchestration

Service

Target Connector

Service

81

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Extra Slides

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

SOA Adapters Best Practices

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

SOA Adapters Best Practices

• Set values for both soft and hard file descriptors in /etc/security/limits.conf to at least 8192.

• Increase JTA timeout in weblogic

console to at least 30 seconds

85

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Adapters Best Practices

Use Save and Update from Weblogic console to ensure adapter

connection factory properties take effect.

Hit ‘Enter’ Key

after changing

Click ‘Save’ after the

connection factory properties

have been updated

Click ‘Update’ after

selecting the adapter

86

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

SOA Adapters Best Practices

• Secure passwords for your EIS using Weblogic Credential Mapping

• Ensure that JMS connection factories, JMS Queues, Datasources are configured correctly in Weblogic Console.

• For non transaction adapters like File & Ftp in a clustered environment, use ‘eis/HAFileAdapter’, ‘eis/Ftp/HAFtpAdapter’. Alternatively configure active-passive failover via “standalone” property in composite.xml for the service/reference

• Configure retries either in composite.xml or in fault policies.

87

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

SOA Adapters Best Practices

• File/Ftp Adapters

• Use throttling parameters for both services and references

• Use De-batching/Chunking/Streaming for large payloads

• DBAdapter

• Use Indexes to improve performance on selects, updates and deletes

• Use throttling parameters such as MaxRaiseSize, MaxTransactionSize, RowsPerPollingInterval

• Use connection pooling

88

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

SOA Adapters Best Practices

• Messaging Adapters (JMS Adapter, AQ Adapter, MQ Series Adapter)

• Increase number of inbound threads for throughput

• Use streaming in JMS Adapter for large payload

89