XQuery
1)
Use of Double Slash
·
Use of double slashes should be avoided to enable better code efficiency.
·
Use of “//” will force the entire payload to be read and parsed.
·
While double slashes ‘//’ imply all the occurrences of the required node,
single slash ‘/’ will ensure the exact node that is required.
Recommendation: Use
"//" only if the exact location of a node is not known at design
time.
Example: “/Order/Address” instead of “/Order//Address”
2)
Indexing the XPath statements wherever possible also increase the code
efficiency. By adding a simple [1], we can index the XPath statements.
Example: “$body/Order [1]/Address [1]” instead of “$body/Order/Address”
Note: Do not index
when you need a whole array of nodes returned. Indexing will only return the first item node of the array.
3)
Extract frequently used parts of a large XML document as intermediate
variables within a FLWOR expression.
OR
If you want to use any intermediate XPath continuously, then assign
that to a variable and use it rather than querying it multiple times.
An intermediate variable can be used
to store the common context for multiple values.
Example:
$body/Order[1]/Summary[1]/Total,$body/Order[1]/Summary[1]/Status,
$body/Order [1]/Summary [1]/Shipping
The above XPaths can be changed to
use an intermediate variable:
let $summary: = $body/Order
[1]/Summary [1]
$summary/Total, $summary/Status, $summary/Shipping
Recommendation: Use of intermediate variables will
consume more memory, but will reduce redundant XPath processing.
4)
Use FLOWR expressions wherever possible
Example:
Normal
Syntax
|
FLOWR
Syntax
|
doc("books.xml")/bookstore/book[price>30]/title
|
For $x in
doc("books.xml")/bookstore/book where $x/price>30
return
$x/title
|
5)
Code should not have any warnings or errors
6)
Looping
minOccurs
|
maxOccurs
|
forLoop
|
0
|
1
|
NO
|
1
|
1
|
NO
|
1
|
Unbounded
|
YES
|
0
|
Unbounded
|
YES
|
7)
Check for NULL values before assigning mandatory fields.
8)
XQuery
Transformation:
a.
XQuery mapper may be more productive (faster)
to use than coding a sequence of low level actions.
b.
An XQuery subroutine may be less efficient
than using the low level built in transformation actions such as Rename,
Delete, etc.
9)
Reduce the number of parameters passing to the
XQuery. Instead you can pass a single
Xml which will have all the parameters mapped.
Reason: Used for effective optimization.
10)
Declare
main function of the XQuery with proper name i.e. with Name of an XQuery.
11)
Update actions like Delete, Insert, Replace, Rename are
more efficient for minor fixes to a document than using Assign with an XQuery that regenerates the entire document,
especially if the document is large.
12)
Split large sized DB Query xml’s to
multiple parts so that XQuery parsing will be easy.
Reason: Design the DB entries in such a way that you would be easily able to
split with respect to some parameters.
13)
Avoid
declaring namespaces above XQuery. It will lead to different
namespace prefixes during runtime. Instead you can put the namespace inline
with XQuery xml tags.
14)
Use Fully Qualified XPath expressions.
Example:
Use /bookstore/ns0:book/ns1:title instead
of /bookstore/*:book/*:title
Reason: This will fetch valid
data in case we have same elements in different schemas.
Should
avoid namespace wildcards like /*: book/*: title
Reason: For better Performance
and clarity.
Proxy Service
15)
Avoid creating many OSB context variables that are used just once within
another XQuery.
Recommendation: Avoiding redundant context variable creation eliminates
overheads associated with internal data format conversions. This benefit has to
be balanced against visibility of the code and reuse of the variables.
16)
It is recommended to use $body/*[1] in any XQuery/XSLT input as it
enables faster execution without invoking XQuery engine.
Reason: A
general XPath like "
$body/Order"
must be evaluated by the XQuery engine before the primary transformation
resource is executed. OSB treats "$body/*[1]"
as a special XPath that can be evaluated without invoking the XQuery engine.
17)
Transforming
contents of a context variable such as
$body could be time-consuming.
Recommendation:
·
Use a Replace
action to complete the transformation in a single step.
·
If the entire content of $body
is to be replaced, leave the XPath field blank and select "Replace node
contents". This is faster than pointing to the child node of $body (e.g.
$body/Order) and selecting "Replace entire node".
·
Leaving the XPath field blank
eliminates an extra XQuery evaluation.
18) Strive to
have a single message representation for as much of the pipeline as possible.
Reason: This makes it easy to insert things at various points
since you don’t have to think about what the current document format is.
19)
If a proxy service has a WSDL with
multiple operations, operational branching is used to handle messages
separately for each operation.
Example:
In
this example CustomerPS
Proxy Service has three matching operations:
GetAllCustomers,
GetCustomerById and AddCustomer
These
will be routed to their equivalents using an Operational Branch. Right-click
the "CustomerPS" icon and select insert into Operational Branch to
branch the incoming request based on the invoked operation to the corresponding
operation of the Business Service.
20)
Batch
file processing: For large but low priority jobs that
arrive over immediate transports like HTTP, consider configuring an HTTP proxy
to accept incoming documents and publish them to a local directory using a
file-based business service. Separately configure a file-based proxy that polls
the directory after-hours and processes the files.
21)
If a proxy service is of type Any SOAP or Any XML, you can use a stage action to determine what the message
type is, and use a conditional branching node in the flow to separate
processing for each message type received.
22)
Conditional branching can be used to expose
the routing alternatives at the top level flow view.
Example:
If you invoke service A or service B based on
a condition, instead of configuring this conditional branching within the route
node, you can expose or highlight this branching in the message flow itself,
and use simple route nodes as the sub flows for each of the branches. This is a
style decision that you must make. Note that the approach of configuring the
route node within each of the branches can get awkward if the fan-out of
messages from the branch is large.
23)
Use “local” transport protocol for “internal
services”.
Unit
Testing:
·
Do nothing i.e. don’t unit test them just test
with other services which may not be that bad as they are like internal
services.
·
Change the protocol in Dev environments
allowing them to be tested individually.
·
By adding SOAP based wrappers for services with
careful governance.
24)
Disable or delete all log actions.
Reason: Log
actions add an I/O overhead. Logging also involves an XQuery evaluation which
can be expensive. Writing to a single device (resource or directory) can also result
in lock contentions.
25)
Set the
appropriate QOS level and transaction settings.
Do not set XA or
Exactly-Once unless the reliability level required is once and only once and it’s
possible to use the setting (it is not possible if the client is a HTTP
client).
Reason: If OSB initiates a transaction, it is possible to replace
XA with LLR to achieve the same level of reliability.
OSB can invoke a back end HTTP service asynchronously if the QOS
is "Best- Effort".
Reason: Asynchronous invocation allows OSB
to scale better with long running back-end services. It also allows Publish
over HTTP to be truly fire-and-forget.
26)
When publishing or routing to multiple
services use the table version of those actions.
Reason: A table
is typically more efficient than a chained if/then/else.
2.3 DO’s and DON’T’s
27)
Users with console write access should never
share a userid because console sessions are managed per userid.
Reason: If two
users that use the same userid make changes in the console, each could affect
the changes the other is making.
28)
DON’T try to develop your entire
solution only on OSB
Reason: OSB
is not alone it’s a part of Oracle SOA Suite, though it’s a general misconception
since it’s available as a separate installer through OTN. Some Project makes
mistake by developing their entire solution on OSB.
29)
DON’T
design state full transactions within OSB
Reason: OSB is a stateless product it’s not design to handle
state-full transactions. For state-full transaction one should use BPEL or BPM
instead of OSB.
30)
DON’T use OSB to execute
complex SQL, SQL Procedures
Reason:
Though OSB provide mechanism to execute SQL and SQL procedure within its
pipeline but it needs to be restricted only for retrieve (select) operation.
NEVER try to execute SQL procedure or insert statements within OSB pipeline.
31)
DON’T develop complex
business logic within OSB’s message pipeline
Reason: Oracle
SOA Suite has OBR (Oracle Business Rule) component to define business logic
than why to define business rules somewhere else in OSB. Define business rule
in OBR expose it as web service and consume your business rule web service in
OSB.
32)
DON’T use sbconsole for development:
Reason: OEPE
create OSB projects and its components in local file system, which can be
easily source controlled apart from that, while considering OSB development
OEPE has many advantage over sbconsole like XQuery editor, split-join etc.
33)
DON’T develop entire message flow with
single stage:
Reason: Each
stage should have only relevant actions and the stage name should clearly
explain what that stage does for other to understand without going through each
and every action in that stage.
·
Multiple stages provide a natural
modularity compared to configuring all the actions in a single stage.
·
Each stage in a request or response
pipeline can have a separate error handling pipeline. If you design your
pipeline with multiple stages, you can avoid writing a single error handler
that must handle all errors by all actions in a single stage.
34)
Use
Split-Join
Reason: Split-Join is used to reduce
latency when CPU is not saturated. Parallel execution is a common paradigm used
to reduce latency while consuming higher system resources. If a set of tasks
have no dependency on one another, they can be executed in parallel. This is
very useful for latency sensitive use cases.
Example:
35)
Use
Throttling
Reason: Throttling is used to protect
back-end systems from spikes in load. Throttling can be implemented creating Throttling
policies for a Business Service within OSB or by using Work Managers at the WLS
level. One can limit the maximum number of concurrent calls to the back-end
service using Throttling.
36)
Use Service Virtualization
Reason: Create additional agility by replacing direct
coupling and to provide a virtual endpoint
with Support of different message formats, move of endpoints, service
versioning, better availability, scalability and Security.
37)
If you are using datasouce for select or query operations, then use
non-XA driver.
38)
Loose
Coupling
It is suggested to implement loose
coupling among different projects so as to remove any dependency among them.
Reason: To call another or
provider service, instead of directly making a service callout to the provider
proxy, we can introduce an enterprise business service with the URL of the
provider proxy which in turn can call the provider business service. This
approach will remove the dependency among different projects.
3 Performance
39)
Enable Streaming for pure Content-Based Routing scenarios.
40)
In addition one may configure the
services on the bus using high availability option so that the service may be
exposed in multiple URIs and if one is not available the others will be
accessed automatically.
41)
Use whatever tooling you are
comfortable with. If performance is an issue use action level performance
metrics to identify the actions to refactor.
42)
The default (unconditional) routing
configuration has the best performance as the message is streamed without
interruption.
43)
Use
Service Result Caching
Reason: It is one of the options that you can
use when you want to improve Oracle Service Bus performance. Service Result caching is used
when we have business service which connects to external service which returns
somewhat static response. So using Service Result Caching we don’t hit external
service for same request instead it will take the response from cache which
improves the OSB performance.
3.1 Processing of large
files
While processing large files, there are
certain parameters to be considered
·
Heap Memory
3.1.1
Heap Memory
Loading large files into memory would require enough heap size. Insufficient heap size will lead to “Out of memory” errors and might also crash the weblogic server.
In order to avoid these error, we
might need to add more memory to the server. But this is not always a feasible
option as the server memory also has a limit. Instead, one of the following
options can be tried.
a.
Content Streaming
b.
Process in chunks
With Content Streaming, the whole object will not be loaded into memory
buffer and hence, we can consume large messages. But content streaming has
certain limitations because the whole object is not loaded in memory. You can find
these limitations at following link and decide if you can implement your use
case with these limitations.
Process in chunks – Another option would be to break the file into smaller chunks and then use OSB to read and process those chunks.
3.1.2 CPU Utilization
When processing large files in OSB, just passing over the content as-is to backend system will not be an issue. But transforming the large content in OSB is the pain point. Any transformation (be it XQuery or XSLT) takes lot of CPU cycles and transformation of huge payloads will consume 100% CPU, resulting in overall drop of the performance. Hence, it is not recommended to have complex transformations and transformations of large XMLs within OSB.
Following are few options:
a.
Opt to move transformations on large payload
to backend systems.
b.
Try for XML Appliances which are specifically
meant for large transformations with little impact on CPU utilization.
3.2 Caching mechanisms in OSB
When caching data in OSB, two points
should always be considered – 1) How much data needs to be cached 2) Which
caching API to be used.
There are two caching mechanisms that
we can look for –
1)
Java Caching System
3.2.1 Java Caching System
This is a distributed caching system
written in Java. This caching system provides a means to manage cached data,
thus speeding up the processing. Beyond simply caching data into memory, it
provides additional features like memory management, thread pool controls, etc.
This is a simple caching scheme where static data will be cached per server.
This can be easily integrated with OSB. But it is not suitable for caching
large amounts of data. It might fail under heavy load in an OSB.
3.2.2 Oracle Coherence Caching
This is the Oracle recommended caching
mechanism where the coherence cluster should be configured in the weblogic
server. This is very robust and stable cache mechanism which can handle heavy
load and large amount of data. The cached data will be available throughout the
cluster.
No comments:
Post a Comment