Think RPA - Think Workflows

Very long time back (may be 12 years back), I was given some series of projects for around two years which were supposed to be developed by using a tool called "MyWorkflow" (Don't try to search in google, you will not find it) That tool was customer's proprietary tool which they developed to create workflows for their internal operations.

I was really reluctant to work on that initially given that expertise on that tool not going to give any weightage to my resume nor that experience not going to add any value to my core .net experience.
Still I did not have a choice except to accept the work and went ahead.

I was given some kind of training on the tool and then I started working on the project (I was the only developer in that project). Though the tool was not that difficult to learn, area I felt challenging was, converting requirements into workflows. Just like regular projects, customer used to give their requirements in descriptive manner and I had to translate them into workflow (I think, I don't have to tell you like, workflow looks like a  flow chart where you define and link series of activities in a sequence to complete a particular task which usually involves review and approvals by different individuals).

In one sentence, it was all about flowcharts, sequences and activities. In MyWorkflow tool, we could attach forms/UI to an activity where user can enter/modify data and we control what fields to show and what fields to hide based on the login user role. After doing one/two projects on the tool, I used to it and started liking it.

Why I'm giving all this rather irrelevant information is here is, when I opened UIPath studio and started creating a new project, I quickly realized it's a kind of workflow tool. When I saw flowchart, sequence and activity words in the studio, I felt like seeing ex-college time crush after ten years. Though there is no link between MyWorkflow tool and UIPath, if at all my comfort levels were really high when started learning RPA/UIPath then that credit must be given to MyWorkflow tool.

Now it goes without saying, RPA is all about creating workflows. Everything in RPA world is a workflow. But mind you, don't think/imagine like normal workflow applications where usually it involves some kind of review/approval mechanism. NO, just assume you are creating a flowchart rather than a workflow if you have any confusion.

Just for analogy, if you compare regular .net programming project with UIPath project, it goes like this.

1. .Net Solution - UIPath Project
2. .Net Project -  UIPath Workflow
3. .Net Class - UIPath Flowchart/Sequence
4. .Net Class Methods - UIPath Activities

My request is, do not try to remember the above stupid mapping. Just for your understanding and just to give you some picture about RPA projects, I've given this way. It is as good as comparing wife and girl friend. If you think both are same then remember it otherwise leave it.

RPA - My first take

I do not exactly remember when I first encountered this word RPA. But when I heard like RPA means Robotic Process Automation, I thought it is something related to physical robots (like those we see in the manufacturing industries) and this technology is targeted to make them work in more smarter way somehow. But when I started reading about it, it does not take much time to understand that it is nothing to do with physical robots nor robotics.

Also, initially I thought like RPA could be a product name which we can buy and use for some kind of automation. This thought also vanished quickly and understand that RPA is a concept but it is not a tool/product.

If you are really new to RPA and came to this blog accidentally then tell me, what is coming to your imagination when you are thinking about RPA at this point of time!? It is not about physical robots/robotics, it is not a product or it is not a programming language. Then what ?

I was having same question during my initial learning hours. When I typed "what is RPA" in google, first definition I got something which is somehow irritating. Then I felt, instead of trying to understand the theory, let us do "Hello World" program in RPA straight away (That time I was not aware "Hello World" doesn't make any sense in RPA).

Then I started searching. Started thinking like, to write some program in RPA, what programming language I need to learn or what software I need to have. During that journey, I came to hear few names related to RPA like BluePrism, Automation Anywhere, UIPath etc...I thought of downloading one of the tool to start writing "Hello World".  

I did not find trial versions of BluePrism and/or Automation Anywhere but luckily UIPath tool was available for free (They call it community edition which is having all features of a fully licensed version). There are some licensing rules to use it in an enterprise organization but as an individual, you can download it and use it forever.

I downloaded and installed.

They call this download as "UIPath studio" like our Visual studio which is used to write RPA programs (Later I came to know that in RPA world, program is called as "Bot"). When I went through UIPath official website, I came across few other software components like UIPath Robot and UIPath Orchestrator in addition to UIPath studio which I downloaded. I was wondering what is the role of these components and why we need to buy/install so many.

I will explain you about these components in detail later posts but to give you an idea, UIPath studio is used to develop your RPA programs/bots. Once you develop your program and deliver to customer, what is needed on their machines to executed the program you delivered ? For this purpose they require a software component called "UIPath Robot".

Then what is Orchestrator ? 

In simple terms, it is web application used to manage your bots. Suppose you developed 50 bots for your customer. Practically it is tedious to deploy/manage/execute these many bots which might be running on different machines and during different times (If the bot is a scheduled one). Also, whenever code of a bot gets changed, it need to be redeployed replacing the current bot. Without a central configuration mechanism it is really hard in huge enterprises/organizes where 100's of bots might be running. Orchestrator is used for this purpose. Through this application, you can quickly monitor all you bots, easily deploy them, schedule bots for running and stop them from running. It is having few other features which we can discuss later.

Ok, let's get back to our task. Creating a "Hello World" program using UIPath. I opened UIPath studio. Like visual studio, it asked me to select a project type but only project type which was obvious to me was "Blank". Rather than worrying about other unknown project types, I clicked on Blank.

Then it asked me my project name. So far it is predictable. I given my project name and clicked on Ok. It showed me below window. After watching this window for 5-10 minutes, I simply closed it and started reading documentation and watching videos in the official UIPath studio. Everything in the below window looked greek and latin to me. I felt there is no point in going for an example without understanding something which looks completely new territory.

That's all I have for now.

What is my conclusion in this "First Take" ?

In fact I'm not very sure what exactly I intended to convey when I said "First Take". I will try to give some logical justification to that heading by saying something about output of any given RPA program with the help of a practical example.

Assume you are an accountant in a pharmaceutical company. Suddenly one morning when you came to the office, you heard that your management purchased a RPA program from an IT company to use in accounts section. Some IT person came and installed the software on a machine and since it is related to accounts section, you have been called for a demo and the program has been launched.

As an accountant, what you expect to see generally when a new program/software installed ?

Some new desktop user interface or some new glassy web screen right ? After that you generally expect that IT guy to tell you how to use the tool and what data to enter in the new application.

But to your surprise, you are not seeing anything new on the system. Whatever existing applications you are using daily to perform your work like EXCEL and SAP are getting opened themselves and data from EXCEL is going into the SAP magically as if some invisible man sitting and inputting data for you. That's it.

Though above example is bit over simplification, it is actually what you can expect from a RPA bot/program.

Unlike other software projects/programs, when you deliver a new RPA work, your users will not see any new application or new interface which solves end users new problems/requirements which were unaddressed by existing applications. RPA programs will just "use" applications which are already running on end user system. RPA programs are never intended to give new features, new functionalities to end user. They just work on other existing applications of your system "just like you work on them". More than that they won't offer anything ! dot !!

SAML

My first comment on SAML is, I don’t like it’s name.

It says Security Assertion Markup Language. I feel like it’s name not properly conveying what exactly it is doing. When I first heard of it, I thought like it’s another new programming language and requires some steep learning curve. But luckily before diving too deep into it I came to know for what purpose SAML is used for.

Later after understanding something about it, I given a thought like what could be an ideal name for this. Of course no one on this universe bothers to know what I would name it but do you know the best part of having your own blog ? 

"You can write any nonsense in that". 

Anyway shall I tell you the name ?

I would have named it as UWAP (User Web Authentication Protocol).

I know what you are thinking. This name is more worse than SAML. right ? Ok leave it. Shall I tell you another name ? 

Here we go !!

EXFA (Exchange XML For Authentication) .

Better ?

No ??

Ok leave it.

Let’s try to understand what it is. 

I read somewhere in a tech book. Author of that book said "Computers are highly unsociable creatures. They won't talk to each other unless you tie them with a cable". 

That author started networking concepts with this statement. 

With the advent of internet we could tie our computer to uncountable number of computers in this universe. But it is only one main side of a story. The other side is, that computer should allow us to enter inside of it in addition to just communicating with it. Right ? Of course I'm bit oversimplifying here. Inside of computer means I intend to say web applications in that computer.

You may ask. What is big deal about it ? If that web application allows users to enter user id and password then they can enter into it otherwise they can't. right ?

True. If there are a dozen of applications like this, what you will do ?

I know your answer.

You will enter user ID’s and passwords of all the applications right ?

If there 20/30 applications like this ?

I know you are getting irritation now. Same answer as previous one right ?

But not all the people won’t have your level of energy Sir. People like me are gifted with poor memory and heights of laziness. You know what? My category of people only are more in this universe. I guess, person who invented this kind of technology probably did so due to the painful life of remembering all passwords.

Believe me. The main advantage of SAML is that only. You don't have remember your user ID and password is one advantage and you don't have to enter your user ID and password is another advantage. 

It is cool right ? Who remembers all passwords except some kind of people who......….. I mean, I didn’t say anything about you.

 If you have to access 20 websites for example, remembering and entering all passwords, maintaining them (each websites defines their own password policies and expiration timings) and contacting their support teams in case of any login issues is an irritating exercise to imagine right ? 

If your Organizations has 1000s of users(which many organizations do), supporting user authentication issues for all those different websites will itself become a nightmare. For this exact same challenge, our super technical geeks came up with couple of solutions and one of the popular one is SAML. But since it doesn't sound nice if they say this technology helps those who forgets passwords, they given a fancy name for that use case and said it is used for SSO (Single Sign On). Means only one thing. You just remember one user ID and password of your organization's main website. For remaining all other applications, just forget it. No worries.

I know your next question.

Without entering user ID and password how those outside applications allows me ? (From now on, I will call these outside applications as "vendors" for simplicity).

Straight answer to this question is, you already entered your credentials in your organization portal right ? It will capture them internally and send your details in an XML file whenever you click on a vendor link from within your organization portal. 

This way of communicating with external applications in XML format is called SAML. 

I know you got another question.

If I simply send my details in XML file how come they are accepting and allowing me ? Is that my password is same for all vendor portals ? Some portals asks my ID, some portals my email ID. But I did not enter them all in my login. How all these are managed ?

Ok. Before you feel bored of reading any further, I will give few statements rather than explanation.

1. When you enter your login credentials, your other profile details can also be pulled by your application right. That means your login application has all your details. Now it can send whatever vendor expect for login. It can be your ID or email or last name or SSN etc.[As a side note just remember, in SSO world, the application where you enter your user id and password is called identity provider]

2. Vendor's won't accept if you send these details in your own XML format. There is a globally agreed standard XML format for this purpose. We need to send details in this standard structure only.

3. There is no need to send your password in SAML. Instead of that they will send a digital certificate along with your details mentioned above. Content of this certificate will be encrypted and added as one of the XML tag in your SAML file. In other words, your details (We can say your attributes) and digital certificate will be sent in a single XML file. This digital certificate is your password like you can assume. 

4. Ok. Instead of password, we are sending certificate. How vendors know if it is a valid certificate? Simple answer for this is, vendor also will have one copy of the same certificate at their end. We need to send our certificate to them so that when your users try to reach them, they will compare certificate data in our XML file with the certificate which you have given to them. Both should match.

 4. Certificate is fine. How does your vendor know you are a valid employee of your organization ? Just by sending some user ID in XML how they are allowing ? No boss. They won't allow like that. There is a pre-requisite activity which supposed to happen even before you try SSO. That activity is, your organization should send all your employee details separately to all the vendors. Then vendors loads all the details in their databases. One technical word given to this activity. It is called "feeds".  Once feeds are completed, then only we can say ground for SAML is all set. 

5. You may get one more question. Like my organization, many organization employees will communicate with vendors through SAML. How vendors differentiate various organizations ? Is all employee details from all organizations won't create any mess ? 

No.

In addition to just employee details and certificate you also need to exchange some other details to uniquely identity your organization. For this, you have to share few additional details and those details also we need to send in our XML file. What details we need to exchange with our vendor ? These details which are supposed to be exchanged are also given a fancy name and is called as "metadata".

That's why whenever any new vendor comes for SSO, first thing your organization will be asking them to share is metadata. As an additional input I'm briefly giving here what details will be exchanged in metadata. Here we go.

1. Your organization (Identity Provider) requires below details from vendor

* Entity ID/Audience (This is your vendor ID. Usually it's value will be like "https://vendorportal.com/xxxxx or it can be like a straight text like xxxxxxxxxxxxxxx" 

* ACSURL (Vendor URL to where you need to send SAML assertion file. It's value could be like "https://vendorportal.com/saml/consume")

* Attributes (Attributes can be many. Your vendor asks you what attributes they are expecting from you. One common attribute will be NameID where you pass your userId/userName)

* RelayState (Optional parameter. This is Vendor URL which will be loaded after successful authentication. Value can be "https://vendorportal.com/dashboard")

2. Your vendor (Service Provide) need below details from your Organization

* X.509 certificate (Certificate given by you. As explained before, Once vendor setup this certificate at their end, for each request from you, vendor will cross check certificate sent through your SAML to make sure you are a trusted entity)

* Issuer URL (Your organization ID. In other words unique identifier of Identity Provider. Sample value can be like "https://otis.com/saml2")

That's it. Once these details are set at both ends, you and your users are all set to communicate with your vendor. 

Hope you got some idea on SAML. Now you can read some serious material about SAML in other super guru's technical websites. If you feel comfortable reading that stuff now then the purpose of this post is solved.

Happy learning !!