Integration Service Is Simply Too Buggy

So I’ve been wanting to try to use the integration service more, but its so buggy that is is unusable.

Currently I am trying to use the ServiceNow connector. The activities to directly work with incidents work, but if I try to use ‘List Records’ or ‘Get Record’ which asks me to specify the record type, well, it crashes and never loads the dynamic values I could then work with.
The triggers in the Orchestrator seem to have the same issue since I cannot select any filters.

I had a similar issue when I tried out the Zendesk integration. The ‘Get Tickets’ activity would bug out and not return values, meaning you had to use ‘Get Record’ and specify the type as a ‘Request’ (Tickets object type doesn’t return anything), however if you try to use the ‘Update Record’ activity using the same details as a ‘Request’ object type it just silently fails, instead you must use the ‘Tickets’ object type, which will update the status but always throw an error when it does…

The only integration I tried that works smooth is the OpenAI one.

Whats going wrong with the testing and release of these activity packages?

1 Like

Regarding the above with the integration service crashing. It was due to an authentication, which was being listed as valid and correct, infact not being valid and correct and causing an error that really didnt show that. I had to sniff the network traffic to get any clue.

I have a list of other issues, now with the Service Now one, the filters on it are broken for more complex fields.

For example via the API an ID will look like this

"id": {
                "link": "https://foobar.service-now.com/api/now/table/sc_req_item/a26d5e8087763d10892f32a40cbb353c",
                "value": "a26d5e8087763d10892f32a40cbb353c"
            },

The integration service will flatten this out to just have id as a string, which is kinda nice but on fields like this the filtering then doesn’t work if you use the activities to ‘Get Records’.

Triggers also don’t work on all the fields.
I set two triggers, on one I think I said the State != 3 on another State !=2, neither fired, even though one always should. If I don’t try to filter on that field in the trigger, but do on others, then it works.

Then updating a ticket status. In the API there are two ways to update it, a PUT or a PATCH.
The Integration Service lets me update the fields in the ticket using Patch it seems, but if I try to change the status it ignores me as the request is not sent as a PATCH.

Then there is the Download Attachment activity, which is a dedicated activity so you’d hope it works well.
Well it doesn’t sadly. There is a arbitrary file size limit on it that I cannot change, no such limit existsing via the API and I can download the same file with it.
Whats worse though is that it uses the iResource thing to automatically save the file to the temp location (which I hate) rather than asking me where to save it, this is a problem because it cannot handle any valid special characters in the filename. For example if you upload a file in Service Now that contains an accented e in the filename (perfectly valid) it just cannot be downloaded via the integration as that e is turned into an invalid character and you get an error.

The activities are also frustrating to use often cause of them being ‘dynamic’. They will often nuke stored values, if you have a filter on you can click advanced editor by accident and even if you press cancel its cleared your values.

I feel like I am only scratching the surface here.

I love the integrations managing the connection, but the activities with them just don’t work.
Please please please please give me a way of making my own API call using the Integration connection, I’d love to manage my connection that way but have more control of the APIs and cover the gaps where the integration service is still lacking.

Edit: oh, and if you restart a job triggered by the Integration service it doesn’t pass over the arguments from the trigger, meaning you cannot effectively start one of those jobs.

Hi @Jon_Smith , Thanks for providing this feedback and we will definitely take a look at these problems.
Would it be okay if I asked you to try out the new ServiceNow activities that we released in Nov 23?
You will need a Studio v2023.10 and above and the activities will directly show up as Available. Something like below:

Furthermore , as we speak we are making efforts to allow users to invoke any API using the Integration Service connections.

Also, for your current problem can you provide the Studio Version and ServiceNow package version?

Regards,
Samrat

Hi Samrat,

I actually have a few support tickets open for various issues like this, some are confirmed as bugs both in the existing and DAP activities.

I couldnt test the DAP ones for Service Now as the org where I have access to it isn’t updated the the latest studio package required.

I heard about some work about making more API’s available, it sounds positive, like I said, if you can perhaps just expose the headers, or make it so there is a scope we can drop an API request into and it will inherit the auth, then we can work around a huge number of these issues.

Another one for you @Samrat_Dutta

(Those activity do not show up in Studio, I have cloud Orch and Studio 23.10.2 installed. I dunno if anyone can see them, seems to be a problem on your end.)

Hi @Jon_Smith ,

  1. for the ServiceNow issue particularly the one which where you say List Records or Get Record fails, can you confirm you have access to all the necessary tables as documented here ?
  2. We identified the ServiceNow that relates to filtering with state and the fix is underway.
  3. Also for the Zendesk issue, what is the package version you are using?
  4. Regarding the Microsoft O365 problem I will let @AlexCrijman chime in.

Hi,

So for issue 1.
Indeed, it was a permissions issue, but took us a looooong time to figure that out, mostly with trial and error with the admin where we kept adding and changing permissions until it worked etc aswell as sniffing API calls using traffic monitoring tools.
The takeaway from that one I feel should be that the documentation should be improved so the specific permissions are properly documented aswell as the Integration Service giving better errors when it fails to aid in debugging.

  1. Indeed, this was accepted as a bug by the UiPath Service desk back in Jan, so hopefully its been on your radar since then.

  2. Honestly I cannot remember, it was for a small POC thing last year and on just a version of Zendesk I made for it. It expired and I threw away the code since it was just for a tech demo thing.

  3. Already connected with Alexandru, I got it solved with the UiPath Support team some months back.