as part of our upgrade to TM v5 I am considering using Service Connections - we don't have any in our old version of TM, so I need to 'learn' how to use them.
In terms of using credentials in the service how do I access the credentials to pass them to the service when the service is invoked?
As an example:
I will create a Service Connection in each environment and add parameters for the required credentials (username, password, host endpoint, etc.)
The KB article about GetRequest mentions code for getting the required credentials as:
String username = svcDef.paramsMap.username
String password = svcDef.paramsMap.password
does the code above work when a service connection is defined for the service?
or do I need to do something like this:
String username = svcDef.svcConn.username
String password = svcDef.svcConn.password
because the credentials are not ServiceParameters, they are svcConn parameters?
any guidance would be appreciated.
Access them from service definition and connection:
String username = svcDef.svcConn.username String password = svcDef.svcConn.password String endpoint = svcDef.svcConn.endpoint ....
With 5.1.0 you can query SvcDef with SvcDefQuery
thanks for that information. I should be able to get that to work.
Is there any documentation about SvcDefQuery()?
The documentation for com.avoka.tm.query only mentions JobQuery, PropertyQuery, SPaceQuery, TxnQuery and UserQuery.
Actually SvcDefQuery will be available with 5.1.0. For now you can just access them from service definition and connection.
Managing multiple service endpoints and credentials for external service calls
thanks for the KB article - I read through that again and got some ideas.
I have a situation where I would like to call multiple end points from one service. The KB article mentions the use of ServiceConnectionDao().getServiceConnectionForName(zipConnectionName), but when I use that the IDE says it is deprecated.
The closet I could find in Fluent SDK is svcConnUpdater, but that behaves differently - it updates a svccConn once I have the target svcConn. But I'm wondering how to get the target as I don't have the equivalent of the "getServiceConnection..."
A service connection is effectively an environment variable.
If I use service parameters rather than service connection then I lose the 'environment variable' aspect and can't have a single service with a defined connection.
I'd like to have one service, and three service connections, so that I can target the connection using variables, e.g. if env == DEV > service connection = svcConnDEV and so on.
is that possible?
Yes it looks like the Fluent SDK is missing this API. I'll put a request through to get this added to the API.
I'm not clear on why you would need the env variable as opposed to just modifying the connection details in each environment or just selecting a different service connection on the service definition tab.
thanks for arranging to get the API call added. When will it be available? next release, or will it be put in as a patch.
I think I am being a bit pedantic and purist about the environment variables for service connections.
I would like to have one service that I can define and deploy to all environments. Then for the service in UAT that needs to connect to different end points, define a service connection for each one. That way I can pass a variable to the service call that can select the correct service connection to target the endpoint; i.e. I want to be able to select the service programatically.
If I use the 'change connection details' approach I need to define all the endpoint variables in the service itself, which means I don't have a single service, I have one for each environment. I could put all the variables in one service, but then the PROD variables would be in the UAT environment; by defining the service connections in the specific environment I can keep PROD and UAT separated.
In any case, once the above API call is available I can achieve the structure that I am after.
Hey Mark, I can't give you advise on the timeframe for the API update as I don't run that team.
But I actually still don't understand why you need it, and why you feel you need to programatically change the service connection.
In each environment you have 1 service and 1 service connection - you don't need multiple service connections in each environment.
You call the service connection exactly the same name in each environment - i.e. if you call it ABC in the UAT environment, then it is called ABC in the production environment.
In each environment the endpoint and auth credentials defined in the ABC service connection are different - in UAT they point to the ABC UAT environment, in Prod they point to the ABC Prod environment.
The service itself loads the same 'Service Connection' no matter which environment it is but the endpoint and auth details are environment specific.
If this is not clear, lets do a call tomorrow.
the above structure works when you ahve a 1:1 relationship between Avoka : target endpoint.
In our situation we only have two Avoka environments - PROD, and UAT. We need to point our UAT at three back end environments - DEV, TRAIN, and UAT. That's why I'm looking at having the three service connections - one to target each back end environment.
In the short terms I'll define the variables in the service and adjust the service connection accordingly.