Page Comparison

Here are the guidelines and recommendations to design, develop, test, and deploy WSO2 integration solutions:

...

• When you create an artifact, use the proper naming convention from the start.
• If an ESB project contains many artifacts related to multiple use cases, name the artifacts by prefixing or post fixing the use case name. 
• Create specific ESB projects for specific use cases. This makes it easy to manage the code/project.
• Design the ESB logic into highly cohesive and loosely coupled modules.
• Avoid creating large, complex mediation code as much as possible. Always follow the separation of concerns design principle and split lengthy logic into separate mediation components.
• When you have a common set of code, implement it in a sequence or a template that can be reused. For more information, see Sequence Template.
• Externalize endpoint and policy references using the Registry. For more information, see Managing ESB projects across environments. 
• Hide sensitive information such as passwords in configuration files using Secure Vault.

...

Using the Log mediator

• When a server encunters encounters errors, you should have enough information about the errors in the logs. 

• To log mediated messages, the best option is to use the Log mediator.
  

• In a production setup, it is not recommended to use the Log mediator within sequences and proxy services other than in the Fault sequences. 

• Using logs with information such as ERROR_CODE is generally useful to understand the issue.

• Put the Log mediators within the Fault sequences, which capture information about errors.
  

• In the development phase, you should use Log mediators in the message flow as checkpoints.

• If you are using the Log mediator to track and troubleshoot the message flow, set the log category to DEBUG.

• If you are in a development environment, ensure that you set the global log level of org.apache.synapse.mediators.builtin.LogMediator to DEBUG.

• If you are in a production environment, ensure that you set the global log level of org.apache.synapse.mediators.builtin.LogMediator to INFO. Setting the log level to INFO allows you to troubleshoot the message flow in production whenever required without having to go through the synapse configuration.

• You should use Log mediators in the FaultSequence to capture information about errors that occur. The logs entries printed via the FaultSequences will be available in the wso2carbon.log that is in the main log file.

...

• You should not write a Class mediator if the intended functionality can be achieved using the enterprise service bus capabilities of WSO2 Enterprise Integrator. Following this practice avoids maintenance overhead. If you want to see detailed information on the functionality of each built-in mediator of WSO2 Enterprise Integrator, see the Mediator catalog.

• If you are writing a Class mediator, ensure that you have a good understanding of the performance impact and possible memory leaks so that you can take these into consideration.

• Be sure to specify a proper package name for Class  mediators

• Be sure to apply all java Java naming conventions and code best practices when you write the code for Class mediators.

Using the Call vs. Callout vs. Send mediators

• You can use either the Call mediator or the , Callout mediator or the , or Send mediator to send a message to an endpoint.

• If you use the Send mediator to send a message, the response goes to the OutSequence (or to the specified receiving sequence).
• If you use the Call mediator to send a message, the response goes to the next mediator placed right after the send Send mediator in the mediation flow.
• The use of Call mediator is recommended for service chaining scenarios.
• Both the Send mediator and Call mediator use the non blocking transport. Therefore, there is no difference between the performance of the Send and Call mediators.

• Behaviour Behavior of the Callout mediator is similar to the Call mediator, but it uses the blocking transport to send the message out. Therefor Therefore, in terms of performance, Callout the Callout mediator is not as good as the Call mediator or Send mediator. If there are scenarios where blocking behaviour behavior is required, you can use the Callout mediator. For example, see JMS Transactions.

  Info
  title Note
  You should not use the Callout mediator unless there is a specific requirement for blocking behaviour behavior in the underlying transport implementation.

  Tip
  The Callout mediator functionality has been merged into the Call mediator in WSO2 Enterprise Integrator. Therefore, you can use the Call mediator and set the blocking flag appropriately to switch between non-blocking and blocking behaviour.

  The following diagram illustrates a proxy/REST API with a Send mediator:

...

Otherwise, the Continuation Stack becomes empty in the Synapse Message Context if you do not use a Call mediator in the target sequence.

Using the Loopback  mediator

Do not include the Loopback mediator in the OutSequence.

...

• You should not specify any mediator after the Send Mediator or the the Respond Mediator.
  
  A message flow must end from these two mediators. Here, the message flow does not mean the current sequence. If you have these two mediators in a sub-sequence that gets called from a parent sequence, then once the message returns from the sub-sequence to the parent, the parent sequence should not include any mediator after the call to the sub-sequence. If you include a mediator after these two mediators, it can cause unusual behaviour in the message flow.
  
  The following diagram illustrates an incorrect use of the Send mediator:
  
  Image Modified
  
  

  The following diagram illustrates the correct use of the Send mediator:

  

...

• Use the Iterate mediator in association with the Aggregate mediator.

• Do not do any configuration after the Send mediator.

• Do proper error handling to handle mediation errors as well as endpoint errors.

• Use appropriate intervals for tasks.

• Use the ForEach mediator only for message transformations. If you need to make back-end calls from each iteration, then use  use the iterate Iterate mediator.

• Do not use the DB mediators (DBReport and DBLookup) with complex SQL queries or in scenarios where you need to simultaneously retrieve multiple rows. Instead, use the data services functionality of WSO2 Enterprise Integrator. For information on how to use the data services functionality, see the Tutorials.

• Use dollar context (i.e., $ctx) instead of get-property(). This is because the get - property  methods search even in Registry if the value is not available in the message context. Thus, it affects performance as Registry search is an expensive operation. However, $ ctx  only checks in the message context. 
  If you need to retrieve a property that you have set on a message, use the predefined XPath variables such as $ctx instead of the get-property() function for better performance. For example, use $ctx: proxy.name instead of get-property(' proxy.name ').
  For more information on the predefined XPath variables that you can use to retrieve a property, and for examples of XPath variable usage, see Synapse XPath Variables.

  Note
  title Note
  The use of the get-property() function can have a lower performance because it does a registry lookup when the value is not available in the message context. Therefore, the recommended approach is to use predefined XPath variables when you need to retrieve a property. You will encounter this performance issue only if you are using WSO2 ESB 4.9.0 or below.

• Reusing a defined sequence
  If you want to repeatedly use the same mediation sequence, you can define it and save it either in the Synapse configuration or in the Registry, with a unique name. Then you can call the mediation sequence from the main sequence as well as from multiple proxy services and REST APIs. The saved sequence can be called via the Sequence mediator or can be selected as the InSequence, OutSequence, or FaultSequence when you define a proxy service or a REST API.

  The following diagram illustrates how a saved sequence can be called using the Sequence mediator:

...

• Use meaningful resource names to clarify what a given request does. A RESTful URI should refer to a resource that is a thing instead of an action. The name and structure of URIs should convey meaning to those consumers.
• Use plurals in node names to keep your API URIs consistent across all HTTP methods.
• Use HTTP methods appropriately. Use POST, GET, PUT, DELETE, OPTIONS and HEAD in requests to clarify the purpose of the request. The POST, GET, PUT and DELETE methods map to the CRUD methods Create, Read, Update, and Delete, respectively. Each resource should have at least one method.
• Create at most only one default resource (a resource with neither a uri-template nor a url-mapping) for each API.
• Offer both XML and JSON whenever possible.
• Use abstraction when it's helpful. The API implementation does not need to mimic the underlying implementation. 
• Implement resource discoverability through links (HATEOAS). As mentioned in the previous section, the application state should be communicated via hypertext. The API should be usable and understandable given an initial URI without prior knowledge or out-of-band information.
• Version your APIs as early as possible in the development cycle. At present, the ESB profile identifies each API by its unique context name. If you introduce a version in the API context (e.g., /Service/1.0.0), you can update it when you upgrade the same API (e.g., /Service/1.0.1).
• Secure your services using OAuth2, OpenID, or another authentication/authorization mechanism. See also Securing APIs .

Working with endpoints

• Do not use anonymous endpoints. Always ; always use named endpoints. As anynymous anonymous endpoints have auto-generated names in the synapse configuration, it is difficult to identify which endpoint is causing the error in case of an error.

• Configure timeout settings appropriately. Timeout  Timeout configurations are required before you go into production with the system.
  
  The diagram below illustrates the typical message flow when a proxy service is involved in a client-server communication. The two connectoresconnectors, Client  Client to Proxy connection and Proxy Connection and Proxy to Backend connection Connection, are are two separate connections that do not depend on each other. Even if one connections connection times out, the other is unaffected.
  
  Here are the important timeout parameters you should configure before going into production:

  Parameter	Description	Configuration File	Default Value	Recommended Value
  http.socket.timeout	The socket timeout of the Passthrough http/https transport sender and listener. You can find the passthru-http.properties file in the <EI_HOME>/conf directory.	passthru-http.properties	180000	180000
  Endpoint timeout	The timeout parameter that you should configure at the endpoint level. You can configure timeout values as required for specific endpoints. Here's a sample endpoint configuration that is configured with timeout parameters. Here, <duration> is the timeout value, and <responseAction> is the action to be taken on timeout. In this example, it is invoking the FaultSequence. Code Block <endpoint> <address uri="http://localhost:8281/services/SimpleStockQuoteService"> <timeout> <duration>120000</duration> <responseAction>fault</responseAction> </timeout> </address> </endpoint> Tip Follow the formula Socket Timeout > max(Global endpoint timeout, Timeout of individual endpoints), and make sure that you set the  http.socket.timeout to a value higher than all other endpoint timeout values.	Endpoint configuration files	synapse.global_timeout_interval	Depends on the use case, Typically 120000
  synapse.global_timeout_interval	Global timeout value for endpoints. Can be overwritten by individual endpoint timeout values. Synapse, which is the underlying mediation engine of WSO2 Enterprise Integrator, is a complete asynchronous messaging engine that does not block its worker threads on network I/O. Instead, it registers a call-back for a particular request and returns the threads without waiting for a response. When a response is available, the registered call-back is used to correlate it with the relevant request so that further processing can be done. If the backend server does not respond, it is required to clear the registered call-backs after a particular duration to prevent possible memory leaks. This duration is set via a timer task called TimeoutHandler. The synapse.global_timeout_interval parameter represents the duration that a call-back should be kept in the call-back store.  Tip If you have configured a timeout value at the endpoint level, the global timeout value is not taken into consideration for that endpoint. For all the other endpoints that do not have a timeout value configured, the global value is considered as the timeout value. You can configure the synapse.global_timeout_interval parameter in the <EI_HOME>/conf/synapse.properties file. The default value is 120 seconds. If you want to support endpoint timeout values that are greater than 120 seconds, set the synapse.global_timeout_interval to a value more than 120 seconds. However, the need to set such large timeout values for endpoints is extremely unlikely.	synapse.properties	120000	120000
  synapse.timeout_handler_interval	Duration between two TimeoutHandler executions.The TimeoutHandler is executed every 15 seconds by default. Therefore, the time that call-backs get cleared can deviate up to 15 seconds from the configured value.  You can configure the TimeoutHandler execution interval by specifying a required value for synapse.timeout_handler_interval in the <EI_HOME>/conf/synapse.properties file.	synapse.properties	15000	15000

• Set the socket timeout value and individual endpoint timeout values appropriately. Use this formula to set timeout values:

  Socket Timeout > max(Global endpoint timeout, Timeout of individual endpoints)

• Be sure to set proper values to advanced configuration parameters, although they are optional.
  The happy path should work with the default values, but you might encounter issues in production when the system does not follow the happy path. For example, if you use the default configurations and as an error occurs in your sequence, the endpoint gets suspended immediately and subsequent messages to that endpoint get rejected without being sent to the backend service. This might not be the expected behaviour in every use case. Therefore, it is important to perform endpoint error handling based on the use case.

• Use the HTTP endpoint for RESTful service invocations. The HTTP endpoint is especially designed to make RESTful service integration easy. For example, it supports url-templates, which is an option to set the http method.

• For RESTful service integration, use either REST APIs or HTTP endpoints. You can use REST APIs to expose an integration solution as a RESTful service, and use HTTP endpoints to logically represent a RESTful backend service.

...

• Ensure that you tune the deployment environment based on the performance tuning guidelines.

• Install all patches using WSO2 Update Manager(WUM) in all environments.

  Info
  title Note
  If you are using WSO2 ESB 4.9.0 or above, ensure that you have all WUM updates installed at any given time.

• Pre-test patches in a test environment before going into the production environment. You should use an automated test suite to do this. For example, you can use JMeter Automation or SOAP UI.
• Pre-test artifacts in a test environment before deploying into the production environment.
• Pre-test configuration changes before applying them in the production environment.
• Automate the process of change deployment. You can use puppet for this purpose. For more information, see the tutorial on How To Use WSO2 Puppet Modules to Deploy WSO2 Products.
• Make sure you follow the production hardening guidelines before going into production or exposing instances to live traffic.
• To port your artifacts from one environment to another, first package the artifacts into a Composite Application (C-App) archive using Working with Tooling, and then deploy the C-App in the new environment.
• It is not recommended to run more than one server instance inside a docker container.

Recommended deployment patterns

...