Built a custom connector with simple OAuth 2.0 client credential authentication. It was connected to a dev system. Then I edited the base URL, token URL, Client ID, and Client Secret to connect it to a staging system.
But it’s still connecting to the original system (dev). I have republished it, same result. UiPath tech identified a bug where our edits are being overwritten behind the scenes, back to their original values.
Anyone ever deal with this and have a solution or workaround?
I’m pretty sure if I delete the connector and create a new one, it won’t be associated with the activities I used in our library (and that library was used in 4 processes). Anyone know how to force the association of activities from one custom connector to change to another custom connector? I do see a “key” value inside the element.json file in the connector definition, not sure if editing that to match the original connector would work.
Never tried this but can you check on Orchestrator while configuring the process, do you get option to choose the connection for this custom connector and its activities like we do get for other out of the box connectors?
You’re looking and thinking at the connection level. Auth info is not entered into the connection, it’s entered into the custom connector. If I create a new custom connector, UiPath doesn’t see it as being to the same system - it won’t show it to you when editing the Process you built with a different connector.
But I’m wondering about that “key” that’s in the element.json file when you download the connector definition. Wondering if I could create a new connector, download it, edit the key to match the original connector, then re-import it. But I’m hoping someone can tell me from experience that it works before I go deleting the one we already have. If it doesn’t work I have to replace all the activities in our library and the four processes using that library.
And this will impact migration to production if I can’t edit the URLs, Client ID, and Client Secret in the connector to switch them to the production external system.
As I understand it, the idea is to not hard code those URLs and have it be defined when you use the connector so they are dynamic.
That being said, I refuse to use the custom connectors cause of a glaring issue that, as far as I know is still not solved (which is quite absurd at this point), which prevents any serious enterprise use.
There is no way for you to share the editable version of this custom connector with your colleagues. Meaning if you leave or are unavailable its impossible to make changes or push bug fixes.
Totally unacceptable in my opinion and means its never worth making a custom connectors and I have to default to API calls I manage outside of the integration service.
Cautioning you on this Paul so you can consider abandoning the custom connector before you are further locked in, understandably this will mean you lose your work so I wouldnt be happy to hear this advice.
As I understand it, the idea is to not hard code those URLs and have it be defined when you use the connector so they are dynamic.
They aren’t hard-coded. They’re configured in the custom connector. The bug is that when you edit the connector to change them, the changes don’t stick they’re overwritten under the hood. Tech confirmed this by looking at logs.
It’s just a connector configured in Integration Services. Anyone can edit it. Not sure what you mean by not being able to share it.
Totally unacceptable in my opinion and means its never worth making a custom connectors and I have to default to API calls I manage outside of the integration service.
Cautioning you on this Paul so you can consider abandoning the custom connector before you are further locked in, understandably this will mean you lose your work so I wouldnt be happy to hear this advice.
I’m starting to lean this direction. They had some really good ideas and certain things work really well, but it lacks flexibility. Of course, if they just fix the bug where you can’t change the auth settings then it would work for us.
To me, the primary deficiency is that you cannot create a connection based on their generic out-of-the-box HTTP connector, then just use that in the regular HTTP Request activity. They say this is coming, but that doesn’t help us now.
The custom connector thing is very close to being excellent.
Have you ever tried this? I’m wondering if this is the solution to our issues - it looks like it would allow us to move the URLs, Client ID, and Client Secret to variables that are entered when creating the connection instead of entering them into the connector.
Oh I think I figured it out. The “Ask User” thing isn’t what I thought it is. What it does is it moves the parameters/settings to the connection. I thought it was something to do with attended automations.
I set the Base URL in the connector to a variable:
As you can see I also set Base URL, Token URL, Client ID, and Client Secret to “Ask User”.
Now when you create a connection it asks you for those values at the connection level. So we can have one connector with two separate connections - one to dev, one to staging. And then when we migrate to production, we just set these values to the production values when creating the connection.
Now we have one connector, and I was able to create separate connections for dev and stage, and now I select from those connections when editing the Process in Orchestrator.
(The one named just “Pega [default]” will be deleted, that’s the original one)
I’m in a different timezone so couldnt respond but happy to see my push got you in the correct direction, thats exactly what I was trying to say that things like this can be configured to prompt the user to define them, so glad you found it.
Regarding the connection sharing.
At least the last time I tried, anyone can use the connection once it is published, but only you could change the connector to, for example, add a new feature or edit it to change it.
If you say another user can infact edit the design mode of the connection, to change the API calls it makes etc, then they must have plugged that gap and I missed the release notes, which is also totally plausible as their release notes are not great.
