String template feature
Answered
Add basic string template support, mainly for the URL part of a micro-service configuration.
Example: https://www.api.com/somerecords?startdate={{ date.now | date.to_string `%m%d%Y%H%M%S` }}
An example is if we need to set a timestamp in the call towards the micro-service or source API. We currently replicate support for this in many custom micro-services.
The example uses syntax from https://github.com/lunet-io/scriban.
-
Official comment
Anders's proposal is a good one. You can use the REST system to provide variable data via the entities that are processed. If that does not solve the problem, then it is probably best solved via a microservice.
Comment actions -
I guess you could support this by putting a rest system in front of the microservice. Then you can build the url for each entity in the dtl. https://docs.sesam.io/configuration.html#the-rest-system
Might not be the prettiest solution, but at least you won't need to implement this in the microservice.
-
This is not for the urls per entity, it is for the url to the system (source/sink). As far as I know, there is no way of supplying dynamic arguments (like dates) to it.
For you suggestion, I would also point to https://support.sesam.io/hc/en-us/community/posts/360008152040-Additional-support-for-chaining-systems :)
-
As mentioned, this is not regarding "per entity processing", it is a shared concern when configuring the pipe (see the url attribute below):
{
"_id": "pipe-with-date",
"type": "pipe",
"source": {
"type": "json",
"system": "custom-url-system",
"url": "my-odata-service/with/datefilter?$filter=StartDate le '{{ date.now | date.to_string `%Y%m%d` }}'"
.
.
.
} -
+1 to the feature request.
Till then this is what i implemented to get over it: https://github.com/sesam-community/dynamic-url-proxy
-
In practice this will have to be evaluated for every entity anyway as it may evaluate to something else depending on timing. It would also require a full expression language – and where would we draw the line between what should be static and what should be dynamic.
I think the best option currently is to delegate this to a microservice like the one Egemen links to.
-
The example shows a GET towards a service, the dynamic part is for filtering on a date in the initial request, this has still nothing to do with "per-entity-processing". As with regards to delegating this to a microservice, I pointed out my view on that in my first comment in this thread. I know this is an option, it is just not a practical one.
Please sign in to leave a comment.
Comments
8 comments