Hosted by Arjun Meda
Speakers:

• Aziz Khan, Senior Director of Product Management at Automation Anywhere
• Vineet Pujari, Senior Product Manager at Automation Anywhere
• Digen Parikh, RPA Lead at Nike
• Ambarish Singh, Senior Software Engineer at Nike

INTRO

In July’s Developer Meet-up we focused on API Tasks in the Automation Success Platform. This may be a new concept for some, and others may already have some familiarity, but no matter—we walked through how to unlock complex automations with API tasks and answered a handful of thoughtful questions from our live audience.

• If you are interested in testing API Tasks in beta, please visit this link to request access. sLINK]

THE INTELLIGENT AUTOMATION STACK OF THE FUTURE

Building end to end processes is complex because more often than not you are dealing with many variables and applications across your enterprise:

• Some applications may be homegrown, on-prem, or SaaSed
• Some applications are accessible by APIs and others are not
• Some processes require human intervention such as exception handling, approving or rejecting things

You need a platform that caters to all of these challenges and variables and the Automation Success Platform is just that. It is a single, AI-powered platform with tech that runs across the lifecycle of automation—from discovery, to using the right tools, to providing the governance and scalability that allow you to build at enterprise scale. And it integrates with your ecosystem in an intuitive, seamless way.
 

INTRODUCING API TASKS

The need for API interaction is becoming more and more critical to your automation needs and API Tasks is our first approach at treating API as a first-class citizen in the product.

What you need to know about API Tasks:

• They run in the cloud
• They integrate with any SaaS application and API endpoint seamlessly
• The tasks are built the same way as your RPA automations and you can use them in a process
• They perform lightning fast—great for dynamic data look-ups, low latency, and they run at native Java speeds. For use cases that require quick responses from your automations, API Tasks are what you want to be using!
• There is no on-prem infrastructure required because they run in the cloud, saving you costs as well as costly windows desktop or VM maintenance

Traditional RPA developers can take advantage of this API capability without having to learn a whole new tool. It’s organically built on top of our existing platform and you can build API tasks just like bot automations with the same infrastructure tools.

We’ve designed pre-built connectors for enterprise applications, and we are accelerating to deliver more and more package availabilities soon to give you the ability to connect to any application in your enterprise. They’re all built with API rather than UI automation, so they are more resilient and will reduce your cost of maintenance.

We’re also working on designing a Connector Builder for you to build your own connector to any application that you can use right away. Coming soon!

If you are currently doing the beta, you will find that within about a week or so, we are going to populate those beta tenants with generative AI connectors. We have gen AI connectors for Open AI, Azure, Google Vertex, etc. Start playing with these to build automations and see how they work!
 

1st Demo - ServiceNow Incident

Building an API Task:

1. From Automation page in Control Room you will see a new button to “Create API Task”
2. Click create and you will be directed to what we’re calling API Task Editor. The only difference between this and theater automation editor is you will see packages that are compatible with cloud such as various CRM packages, Salesforce, Servicenow, Sharepoint, Workday, as well as generative AI packages (Google Vertex AI, Microsoft Azure AI, and Open AI). These packages are drag and drop, so there’s no new learning curve here, you can build you API task just like you build any other type of automation in the ASP.

Executing an API Task within a form:

In this example, we utilize the ServiceNow package, the authentication action, then the create record action to submit the incident in the incident table. We want to plug in the API task to a form and take these inputs upon a “Submit” button click to create an incident in ServiceNow and generate a new incident ID. If you have an API task ready and a form ready - how do you connect the two?

1. The form has 3 fields: submitter name, description, and urgency, as well as a Submit Issue button.
2. Go to Form Rules, add a rule where you will specify the action to complete the API task. In this case: “Submit Issue” button click.
3. Specify the form action by selecting “Get value from API call”
4. Select API bot by hitting “Browse...” and then select your ServiceNow Incident API task.
5. Then the UI will automatically offer you input and output variable mapping. Configure those variables and you’re ready to go.
6. Test the task. We see a new incident number is populated in the form for the user to see within milliseconds.

2nd Demo - Insurance Quoting

An insurance agent automates a home insurance quotation process across several applications. With API Tasks, this process is reduced from 60 minutes to only a couple of minutes, all while the customer is on the phone.
 

1. Start in Salesforce with Automation Co-Pilot embedded.
2. Zoe, the insurance agent, initiates the quotation process in Co-Pilot which automatically populates the customer’s data from Salesforce, saving time on manual data entry and reducing errors.
3. She submits the process and an automation retrieves data on the property.
4. Zoe selects a few other options regarding insurance coverage based on the needs of the customer and then submits this selection. In the background, an API task is executing and getting various pricing on packages for the property using REST commands and Json package, all in a matter of seconds.
5. The API Task returns 4 options that Zoe proposes to the customer. The customer makes a selection and Zoe submits that selection.
6. A quotation is generated using the price that Zoe just quoted and an approval request is automatically sent to Tomas, Zoe’s manager.
7. Tomas receives a notification in his system of choice within Co-Pilot. He approves it right away and submits it, which will send an approval notification to Zoe.
8. With the approval, Zoe can email the quote to the customer and we’ve added an API task using generative AI to draft that email for Zoe. She can review and edit the email text before hitting send.

Creating that process was as simple as dragging and dropping bot tasks and API tasks and configuring them in bot repository.
 

ROUNDTABLE WITH NIKE ON API TASKS

The Nike team has been participating in the beta for API Tasks and has graciously joined us to talk about what their experience has been so far.

Digen and Ambarish are part of the product innovation and consumer creation department, which is the core department where Nike products get conceptualized, designed, and developed. They develop automations so Nike can stay nimble to cater to rapidly increasing market demand. Their primary objective is to accelerate Nike’s digital transformation journey by adopting intelligent automation solutions, and their vision is to use the Automation Success Platform to bridge the technology so RPA can be used for Legacy systems and processes. Simultaneously, they are testing how they can leverage the huge potential APIs to solve business problems with speed, scale and agility.
 

In a nutshell, they are adopting an API-first approach at Nike to implement a scalable and sustainable solutions for the long-term.

Regarding API Tasks and the beta experience—what are some the key aspects that will drive value in nike and what appeals most to you from a developer perspective?

• API Tasks will definitely lower the barrier to entry for our API-first approach across the organization. While exploring API Tasks, we have observed that they provide the true cloud experience, which guarantees performance on par with other traditional technologies like Java, .net, Q#, etc. One more benefit we observed is also the tenancy. Infrastructure maintenance is the key challenge for many organizations, and since the platform provides this infrastructure maintenance, it’s more cost effective and will help us scale the program more easily.

Can you share any use cases you’ve tested using API Tasks?

• A recent use case involved us hitting a bunch of APIs similar to the demo we just saw. We received a 100-page click-by-click document from the business, and at first glance, we knew if we followed the UI scraping route we would not be able to deliver on time. Instead, we went on an API discovery of those applications that the business came to us with and fleshed out the APIs. Once we had that, the integration with the Automation Success Platform was seamless. In fact, we used the automation platform as an orchestrator, invoking the APIs, consuming from the endpoints, and then implementing the self-healing logic with an element of traceability and audibility as well. So if things went south when we were running in production, we would have the exact instance, system, and transaction where things went wrong and we could resume from there without having to touch what had already been worked on. We were able to deliver this process from start to finish in record time of one week. That would have been impossible if we had taken the traditional UI scraping route.

AUDIENCE Q&A

1. Can we invoke API tasks from the regular taskbot?
   • Currently we do not support that, but we are working to support it in the next release.
2. Is there a default timeout for API tasks?
   • Right now we haven’t specified timeouts. So if your API needs a few seconds, you can run the API task and it will get the acknowledgment to you and once the API task completed its execution, then you can initiate a callback and continue the process.
3. What about the API’s authentication?
   • If you’re authenticating with a third-party application like Salesforce or ServiceNow, you will use the same authentication credentials inside of the API task. So there is no change with respect to authentication API tasks. However, we will start supporting OAuth2’s in the future, so in A.30 you’ll see additional authorization-related capabilities.
4. If the API errors out, how do we get the error messages from the API and where do we see those messages?
   • We have a comprehensive set of audit logs where you will find error messages and any kind of debug.
5. Does this work similarly for on-prem set-up as well?
   • API tasks is cloud-only in the initial release. We will support on-prem in the future, but not at this time.
6. What’s the difference between AARI and API tasks?
   • API tasks is really a component. AARI is the process composer environment and API Tasks give you the ability to tap into your API assets in the enterprise. So if you want to build a complex process that requires some screen scraping, you would use RPA tasks for that. But if you have data sitting in Salesforce or ServiceNow, API Tasks may be more efficient in those cases. Especially with large language models (LLMs) where you need interactive sessions and need data quickly, that’s where API Tasks come into play.
7. Regarding role-mapping, is there a specific role or license to be assigned to use API tasks other than the AARI user license?
   • There are no special roles. What you’ll see with A.30 is there will be a system user available, that’s going to be the default for any API Task executions. You can change that on your own for auditability purposes, but we wanted to make sure that wasn’t one more step you needed to do to get started with API tasks right away.
8. What’s the difference between an A360 with REST web service command and API Tasks with a REST web service?
   • We wanted to make sure there was no inconsistency in the way you build automation—no new learning needed on your end as a developer. You can pick this up and run with it immediately. So the packages are exactly the same and will behave exactly the same, we haven’t made any changes other than to make them compatible with API Tasks. The fundamental changes are actually in the architecture, where these things actually run. When you run a bot task with a REST package, it will actually go interact with a bot agent on your VPC or your desktop. When you run an API task with a REST package, the API endpoint actually gets called by our device in the cloud. That’s where you get the performance gain. So for developers, there’s no change for you, but architecturally there are some changes.
9. How can we build our own API connectors?
   • Very soon in A.31 you will have a feature in A360 that will allow you to create your own API connectors. You won’t have to wait for Automation Anywhere to release an official package. We will circle back in another dev meetup and show how this is constructed and get feedback from the audience.