Hello Experts,
Can someone help me to understand about triggered task execution.
For eg:-
User1 created one triggered task and share the triggered task URL to User2 for execution.
So User1 is task owner.
When user2 hit the triggered URL,then in dashboad User2 name should come right ?instead of User1 name.
if Username is showing owner information in dashboard then how to get User2 details,because task is executed by User2 not User1 of Same org.
You are correct – when the pipeline executes, it executes with the permissions of the task owner even if another user triggers it. So in the dashboard, it shows the task owner rather than the user who triggers it because that’s really the user who is executing the pipeline.
A triggered task can be authorized by using a username/password or a bearer token. When the task is triggered, the method of authorization is recorded. In the case of a username/password, it would store the username. So in your example it would show user2 there.
I don’t see that detail exposed anywhere in the UI. Let me ask around or see if an enhancement should be filed.
Thanks @tlikarish for response. we are looking for user2 information.
Sounds like this isn’t exposed in the UI yet. I’ll work on getting an enhancement filed for this feature.
@tlikarish what is use of service account, it seems to be useful for authorization to call a trigger task but it is failing but task owner id and password is working as basic authorization.
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.
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
