• Strive to have a single message representation for as much of the pipeline as possible. This makes it easy to insert things at various points since you don’t have to think about what the current document format is.
• Always configure the service-level error handler. For non-SOAP services the built-in error handler only returns a transport error code since there is no standard error response document like a SOAP fault that it can auto generate.

 

• When publishing or routing to multiple services use the table version of those actions. A table is typically more efficient than a chained if/then/else.
•  If a proxy service has a WSDL with multiple operations, it is generally recommended to use operational branching to handle messages separately for each operation.
• 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.

 

• XQuery Transformation:
  • XQuery mapper may be more productive (faster) to use than coding a sequence of low level actions.
  • An XQuery subroutine may be less efficient than using the low level built in transformation actions such as Rename, Delete, etc

Recommendation: Use whatever tooling you are comfortable with. If performance is an issue use action level performance metrics to identify the actions to refactor.

 

• If the document is small doing a dozen update actions instead of a single Assign might be more expensive.
• 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.

 

• The default (unconditional) routing configuration has the best performance as the message is streamed without interruption.
• Users with console write access should never share a userid because console sessions are managed per userid. For example, if two users that use the same userid make changes in the console, each could affect the changes the other is making.

 

• ALSB service bus leverages the High Availability features of Weblogic service. The service bus uses the same cluster configuration and provides high availability through the cluster configuration.
• 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. Finally, data dependent routing feature of the service bus will help users to route the messages to various end points achieving high availability.

 

• 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.
• Conditional branching can be used to expose the routing alternatives at the top level flow view. For 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 subflows 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 fanout of messages from the branch is large.

 

• A single stage in a pipeline is often sufficient for most use cases you configure. However there are cases for which you might consider multiple stages.
  • 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.
  • If you use the resume action (in an error handler) or the skip action, the behaviour is to resume processing at the next stage in the request or response pipeline. Therefore, depending on the logic you want to enforce, it can be a good design principle to put actions subsequent to a resume or skip action in subsequent stages.