This session presentation is aimed at UiPath Developers and Solution Architects who regularly create JSON objects, who are interested in a coding standard that is efficient, repeatable and easy for others to follow. The chapter discussion is relevant to anyone interested in creating a cluster of RPA expertise in the Central Scotland area.
Agenda :
- A little context: explaining UI and REST API interaction and associated challenges
- A brief tour of JSON: a whistle-stop tour of the JSON syntax, just so we're all on the same page
- Building JSON using UiPath Activities: a couple of examples JSON payloads, and discuss the implications of using traditional UiPath activities to build these objects
- Problems with the activity approach
- Leveraging .NET integration: revisiting the examples using code, with a code walkthrough explaining every line
- A word of warning
Concluding remarks and going further: basically a recap, then ask the question "what if we aren't sending JSON, but receiving JSON?" - cue LINQ teaser
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
Leveraging UiPath .NET integration to build JSON
1. Leveraging UiPath .NET integration to build JSON in
a simple, readable and repeatable way
By Jack Dale
Monday, 24th October, 2022
www.vkyautomation.com
2. Contents
A Little Context
A Brief Tour of JSON
Building JSON Using UiPath Activities
Problems with the Activity Approach
Leveraging .NET integration
A Word of Warning
Going Further
Concluding Remarks
3. > Our automations must interact with a range of
applications and systems.
> UiPath has a sophisticated UI detection system,
but this may not be consistently reliable.
> Automations are at the mercy of the applications
they interact with.
> Alternatively, our automations can interact with
APIs.
> Major architectural styles: SOAP (typically uses XML)
and REST (typically uses JSON).
> REST requests can be complex and difficult to
construct in UiPath, but not anymore!
A little context
4. > Syntax borrowed from JavaScript.
> Composed of 6 core structures
> Objects -> ‘{ }’
> Arrays -> ‘[ ]’
> Strings
> Numbers
> true and false
> null
> Objects are made up of key-value pairs (called
“properties” in JS speak).
> Arrays can contain any of the structures, but not
key-value pairs.
> Arrays are non-homogenous: an array can hold
objects and strings and numbers etc.
JSON (briefly)
8. > To construct the previous example using UiPath
would require:
> An assign activity to create the top-level JSON object.
> 10 Invoke Method activities to add each property to
the top-level JSON object.
> Perhaps an assign activity to format the date-time
for ‘createdAt’.
> What about activities to format phone numbers and
emails?
> Things can get worse…
Constructing JSON using UiPath activities
11. > Workflow pollution:
> Lots of almost exact duplicates of a single activity,
just with different parameters.
> Reduced readability:
> Non-standard differentiation - how should we tell the
difference between each activity? With comments?
Annotations? Renamed activities?
> Likely to make a mistake if adding more
properties later in development:
> One of the already existing activities must be copied,
pasted, relabelled, and its arguments changed to the
required values.
Problems with the activity approach
12. > As UiPath is built on .NET, we can use its
integration to our advantage.
> Use the ‘dynamic’ C# keyword.
> Bypasses compile-time type checking.
> Checks are done at run-time instead.
> Let's us add properties to a JObject in a manner
more akin to actual JavaScript.
> There are exceptions to the rule.
> No more untidiness!
> A single Invoke Code activity compared to many
Assign’s and Invoke Method’s.
Have no fear, Invoke Code is here!
15. > VB.NET does not have a ‘dynamic’ keyword equivalent.
> Instead use ‘Option Strict Off’.
> UiPath has ‘Option Strict On’ by default - there is no way to turn it off.
> We can still reap the benefits of Invoke Code, we just can’t build JSON JS-style.
A sidenote about VB.NET
16. > Certain property names can only be added using
the ‘Add’ method.
> This is easy to do though, simply type:
<jObj>.Add(<property name>, <value>);
> Where:
> <jObj> = the name of your JObject
> <property name> = your property name*
> <value> = the value being added
* Property names that are not alpha-numeric or
‘_’ must be added with the Add method.
* Google provide a best-practice style guide, found
here
A word of warning
17. > We’ve discussed building JSON to send REST
requests, but what about receiving responses?
> Believe it or not, the very same principles apply:
> JSON responses can be complex and deeply nested.
> We could extract the data we need using UiPath
activities, but…
> Unless the JSON structure is very simple, we will fall
into the same trap as when sending requests.
> As before, we can simplify our workflows using
invoke Code, but there’s a twist.
> To help us extract the data we need, we can use a
language feature called LINQ, but that is a story for
another time…
Going further
18. > Using an API is always preferable to interacting with GUIs.
> Constructing JSON doesn’t need to be arduous and
complicated.
> Adding JSON properties using standard activities is
cumbersome and makes workflows unreadable.
> We can replace our activities with a single Invoke Code.
> Using ‘dynamic’ to bypass static type checking combined
with the JObject .NET class, we can compact JSON
construction to a single activity.
> Property names which contain non-alpha-numeric
characters (except ‘_’) must be added using Add.
Concluding remarks
