Forum Discussion
We did implement this feature now, so you should be able to see the invoker of the trigger task recorded in the runtime statistics on the pipeline dashboard.
@sanjaynayak, a service account is generally used as an account dedicated to executing triggered tasks. You can read about how to create one and some of the nuances in the Creating User documentation. When you create a service account it’ll have its own user id and password that can be used to authenticate a request to a triggered task. Can you verify that you’re using the correct credentials to trigger the task?
@tlikarish Service account creation was not a problem, account permission was missing to corresponding project trigger task. It worked.
Let me summaries what is current feature and what can be enhanced related to trigger task.
1- End client who is using trigger task, can’t use bearer token due to security gap and that’s why we moved to basic authentication.
a- Some client they are calling trigger task using some program, they can use trigger task url, user id and password to connect snaplogic and good to go.
b- Some other client they are calling directly url from their website and they don’t have mechanism for authentication. It seems like we don’t have work around for this. Still I am checking what can be done over here.
2- As part of bulk submit, trigger task is not queuing the request in case previous request is running, in order to avoid this issues, workaround is disable the trigger option. But challenges here is all request running concurrently and threaddump got increased and it is depend on system(snaplex) configuration. I don’t think we have any other option for us now, in case we have other choice, we will verify.
- tlikarish5 years agoEmployee
Hi @sanjaynayak,
This is getting a little off topic from the original post. I’ll try and summarize some recommendations, but let’s try not to let this thread go on too long or it might be hard to find. If you want to continue the discussion, let’s start a new topic in Enhancement Requests - SnapLogic Community category.
For trigger tasks, I’d recommend using the bearer token for these kinds of things. If customers aren’t able to use that authentication mechanism for security reasons, then you could look at some of the API Management policies. There is support for authenticating against third party services using OAuth, like Github, as well as an API Key authenticator, and more generic Call Out Authenticator.
There is some support for this functionality with the Ultra task feature. An Ultra guarantees that each document will be processed at least once (it will not guarantee it won’t be processed more than once, so incorporate that into the pipeline design) and you can limit the number of concurrent documents being processed using the “max in flight” setting. If there is only 1 instance and max in flight is set to 1, then a single document will be processed at a time and others will get enqueued as they’re received.
Hope this helps you with your clients.
Best,
Tim