Thank you @bojanvelevski for the detailed solution and steps.
I was planning to use column.replace() instead of column.replaceAll() however I see your point, for removing the opening {, column.replace() would have worked seamlessly but for ending }, column.replace() might have removed the first occurrence of } instead of the actual end }.
Thank you again for the explanation, really means a lot to me. I will try the above-mentioned steps and keep you posted on how it goes…
@bojanvelevski: Let’s assume that I’ve to remove all the existing { }, should we be using the column.replaceAll() then?
Really appreciate your help and insights into this one.
Thanks!
Regards,
DT
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
