Best wishes!

For application integration, things look very promising according to Gartner: "organizations will spend 33% more on application integration in 2016 than they will in 2013".  That's the main message of Gartner's report "Predicts 2013: Application Integration".

 

Stephanie Mann of Techtarget reports on that same message being communicated by Gartner at their AADI conference, some interesting snippets from her article:

• "What you want me to say is that cloud APIs [application programming interfaces] are solving your problems, and that REST is the answer," Lheureux told his audience. "But we're not just automating the process and sending messages. We're looking at actually collaborating more at the process-execution level."
• "More than 50% of the cost of implementing new systems will be spent on integration in the next five years," Schulman said. "Our architectures are obsolete; the way we approach integration is obsolete; and the way we think about integration development is increasingly obsolete."

Best wishes for 2013!

WebMethods SalesForce Adapter

With the upcoming services in the cloud, integration with and in the cloud is a hot topic. One of these cloud services is SalesForce. WebMethods comes out of the box with a solution to connect Integration Server with the SalesForce platform. To do so it makes use of the SalesForce adapter.

Version 7.1.1 of the adapter allows us to connect to SF using the SOAP API version 23. It is not supported to make a connection using another version of the API. This will be possible on the future webMethods 9.0 release using CloudStreams.

The adapter allows us to perform the following operations, using webMethods services:

• Create
• Delete
• Query (only for queries on a single object)
• Retrieve (only for queries on a single object)
• Update
• Upsert
• Utility: getServerTimestamp, getUserInfo, resetPassword, sendEmail, sendMassEmail, setPassword

It is also possible to retrieve upsert and delete notifications from the adapter.

One of the biggest advantages of the adapter is transparency. You only have to enter the SF endpoint, a username and a password and the adapter will keep track of the login procedure, session management and session renewal. Clustering and connection pooling are possible since the adapter is incorporated in the adapter runtime framework.

Besides the advantages the adapter has some disadvantages. Not every SalesForce operation is supported. Non-supported operations are convertLead, emptyRecycleBin, merge, process, search and undelete.

It’s also not possible to call custom web services on SalesForce using the adapter. To do so you have to make use of the standard web service descriptor functionality. This means you need to connect manually and keep track of your session.

Complex queries are not possible. The adapter allows you to select a single object, and then you select the fields of the object you want to get as output. Selection criteria can be added too (some kind of where clause), but queries over multiple objects or sub queries are not possible.

There is also a version 8.2 of the SF adapter. It requires at least version 8.2 of the Integration Server but addresses some of the 7.1.1 shortcomings:

• convertLead is now a service in 8.2
• there is now a custom query service that allows you to type in any SOQL query
• all the services mentioned in the report can indeed be invoked using regular Web Services descriptors
• the 8.2 version also has a service that gives you the SF.com token, which can be used with the Web Service
• descriptors to invoke these services along with custom web services on SF.com

Setting up an intelligent load-balancer group in IBM Datapower

The Datapower appliances offer a lot of functionality, but not all configuration options have clear documentation. In this blog I’ll present a typical setup for an intelligent Load Balancer Group.   

What we want to achieve in this setup is an intelligent load balancer that can do fail-over, but that excludes the members which are known to be in 'down' state from these fail-over tries.
In case none of the members is considered ‘up’, we want an immediate error-response and no extra waiting times for retries to backends that will probably fail. One of the reasons for such an approach might be that we want to isolate problems with a specific backend and make sure our Datapower appliance is not affected by a huge number of open connections (e.g. due to to a very high load and a relatively large time-out value). If the amount of open connections keeps on rising we will eventually reach the boundaries of the appliance and start receiving out-of-memory errors...

First of all a short explanation on the different states of a member of the load balancer group:  
- ‘up’: this is the default state of a member of the load balancer when it is added, but this state can also be reached when a member that was ‘down’ succeeds a health check. 
- ‘down’: this state can be reached when a health check on this member failed or when the member is manually disabled. 
- ‘softdown’: aka dampened, when an actual request reaches a connection error, the state of the member that caused the error is set to ‘softdown’ for a period specified in the ‘damp time’.

Healthcheck
After adding the members to the load balancer group we are going to add a health check. The default health check sends an empty soap-request and validates the received response against the entered xpath. Since the default xpath is ‘/’ the health check will be valid if any xml-response is received.
 
One option needs some extra attention: the ‘Timeout’ value. This value represents the amount of seconds before the health check fails with a time out. However, since the health check request is done using a user agent object, in reality the time out of the user agent is the one that is used.

Main load balancer group settings

The options that need some extra clarification here are ‘Do Not Bypass Down State’ and ‘Try Every Server Before Failing’.
- ‘Do Not Bypass Down State’: This property should ensure that when all members of the load-balancing group are down and a new request for that group is made, no attempt will be made to connect. However you should note that the load balancer is only behaving like this when this property is set to ‘On’ AND the property ‘Try Every Server Before Failing’ is set to off.
- ‘Try Every Server Before Failing’: As stated above, this property overrules the ‘Do Not Bypass Down State’ when it is set to ‘On’. The Datapower help-file will tell you the following:
This text is a bit confusing, since in reality we observed the following behavior: not only dampened and healthy members, but also unhealthy members are tried. This can cause some serious problems in case of time-out errors on multiple members, since each member adds this time-out to the total execution time... When this property is set to ‘Off’, the behavior observed is that in case of a failed connection attempt, the next member in state ‘Up’ is tried.

For the intelligent load balancer that we want to create we need to set the property ‘Do Not Bypass Down State’ to ‘On’ and the property ‘Try Every Server Before Failing’ to ‘Off’ as can be seen in the screenshot below.
Conclusion
With only a few configuration steps we can create an intelligent load balancer. The load balancer actively executes health checks with SOAP-calls and maintains a list with the status of its members. When a connection error occurs during an actual call from a client it automatically retries to make a connection with one of the known healthy members. When no member is ‘Up’ the call will directly fail and therefore prevent an exponential rise of open connections in case of a high load.

Author: Tim