Connecting to Web Services that Provide an Authentication Token

Some web services require a “login” call prior to making any other web service calls.  The initial login call returns an authentication token, and that token must be included in subsequent web service calls.  The token usually has a limited lifespan, so the login call must be made again when the token expires.  One (inefficient) way to accomplish this would be to make the login call prior to making every other web service call.  This article discusses a better approach of reusing the authentication token when possible.  It is based on an actual Interface implementation where the web service provided an authentication token that was valid for 24 hours.

Transaction attributes as their name implies are tied to individual Transactions.  In order to make the authentication token available across multiple transactions, the Store Attribute Processor will be used.  This processor is included in release 13.17R2 and later.  If using an older release, please contact PilotFish Support and request the StoreAttributeProcessor.jar file.  Then add it to the lib directory of your interface.

Implementation involves configuring the following three Routes:

1. “Login Request” route
   • Use a Programmable (Trigger) Listener so that we can call this from the main route
   • Add the Store Attribute Processor (at the listener stage) configured to retrieve an existing authentication token (provided it is not more than 24 hours old) into a transaction attribute called “Login.authorization”
     
   • Routing rules configured to call one of two Transports:
     • If “Login.authorization” is “DefaultValue” then a valid unexpired token was not found.  In this case, call HTTP Post transport to make an initial login call.  The details of that call depend on the requirements of the specific web service.  The Response Listener should be set to send the response to the next route.
     • Otherwise, call Synchronous Response Transport to return the existing token
2. “Login Response” route
   • This route handles the response from the login call
   • Use the same Store Attribute Processor to store authentication token.  Note that the Timeout does not need to be set here.  The timeout is applied when the token is retrieved, not stored.
     
   • Finally, use the Synchronous Response Transport to return the token to the calling route.
3. The main route handles incoming requests by first calling the above routes to get the login token and then perform the web service calls.
   • First, add a Call Route processor to the Listener that calls “Login Request” to get a login token.  The Synchronous option should be selected so that this route waits until the login routes have retrieved the login token.
     
   • Use the token from the “Login.authorization” transaction attribute when making your main web service requests.

With the above approach, the login request will only be made as needed which should greatly improve the performance of the interface.  The two login routes encapsulate the work of storing and retrieving the token and making the login call when necessary.  Then routes that will be making web service calls requiring the token just need to add the Call Route processor to call the login route as shown above.