Overview – Using MuleSoft Composer for Salesforce and External Systems
Integrating data with MuleSoft Composer for Salesforce and MuleSoft RPA easy. This article and corresponding video will show the straightforward process that enables updating Salesforce with external data from a MuleSoft RPA process.
As prerequisites, the following are required:
- Salesforce, MuleSoft Composer, and MuleSoft RPA licenses
- Anypoint Platform Credentials
- MuleSoft Composer Credentials
- Salesforce Org Credentials
- Client ID and Client Secret for Connected App with “RPA Invocable Process” scope
- Mulesoft RPA Tenant Name
- Invokable MuleSoft RPA process in Production Phase
To see how to generate the invokable MuleSoft RPA process, the MuleSoft RPA tenant name, and the Connected App details, see our prior posts: Invoke MuleSoft RPA Process via HTTP and Postman Part 1 and Invoke MuleSoft RPA Process via HTTP and Postman Part 2.
The use case walked through here will show how to trigger a flow upon creation of a new Salesforce record, call a MuleSoft RPA process, and then update that Salesforce record with output data from the MuleSoft RPA process execution.
Step-by-Step Process in Composer
To start, log in to MuleSoft Composer, and from the main flow, go to Create new flow -> From scratch :
The process asks what should start the flow; choose a System Event of type Salesforce. This configures the flow to be triggered by Salesforce activity:
Add a new Salesforce connection; give a useful Connection Display Name and click Connect. This will pop up a Salesforce login window which requires entering valid Salesforce credentials:
Upon entering of valid credentials, an “Allow Access?” screen is shown. Allow access. At this point you have a successful Salesforce connection and are ready to configure the details of the trigger.
Fill in the form to provide the trigger data. The example here triggers upon any new Product record being created. It polls every 15 seconds for newly-created Products:
After configuring this, the Trigger configuration is complete. Hit the plus button to create a new action step.
For this use case, the next step should also be a System Action. This System Action is of type MuleSoft RPA:
Add a new Mulesoft RPA connection. Provide a meaningful Connection Display Name, and use Authorization Type = OAuth 2.0 Client Credentials. Then use the prerequisites mentioned above to fill in the RPA API URL, the Client ID (using the Connected App client ID), the Client Secret (the Connected App client secret), and the Token URL (this should be a standard value: https://anypoint.mulesoft.com/accounts/api/v2/oauth2/token). After configuring this, click Connect:
Once the connection is successfully established to MuleSoft RPA, select the relevant RPA process to be called as part of this Composer flow. And for Output, select “Use response in this flow”. The use case illustrated here also adds an input field to the RPA process; it sets the “BuildCategory” activity parameter for the RPA execution equal to the name of the Product that was created to trigger the flow:
The flow is now configured to call the MuleSoft RPA process. The use case requires one more step; this step is another Action Step to update Salesforce with the RPA process’s output data.
Hit the plus button to add one more Action Step, and once again select System Action. Select Salesforce as the action type. Use the Salesforce connection that was created earlier in the process. This time, the action is “Update record”. Object Type is the same object type that was used to trigger the flow (Product). An ID (Product ID) is required to tell Composer which object to update. Set the value for Product ID = Product ID from the “On New record” trigger in the input box:
Add one more field from “Select Additional Fields” to add Product Description; this is the field that will get updated with the RPA output data in this use case. This particular use case uses a Custom Expression to enable multiple RPA output fields to be utilized in the Salesforce object update. Configure the expression as shown in the screenshot and hit Apply:
After applying the custom expression, the Update action is successfully configured:
Click Save and name the Composer flow appropriately. Once saved, click the Test button to test out the Composer flow. This will have Composer start polling for newly-created Product records in the configured Salesforce org:
Test it from Salesforce
With the Composer flow running its Test, open up Salesforce. Go to the Products tab. Click New:
Create a new Product with a useful Product Name (“Table” in this use case). As mentioned in the Composer setup section, the Product Name is mapped to the RPA BuildCategory input activity parameter. Leave the Product Description blank, as the Composer flow will be updating that field with RPA output. Click Save to create the Product:
After clicking Save, go back to Composer where the Test is running. Within 15 seconds (the polling time), the Composer Test should move to a status of “Processing…”:
It may take a minute or two for the RPA process to execute. Once it does, some output will show in each Action Step. The screenshot below shows the output data from the RPA process:
Next, verify that the Salesforce update completed correctly by going to the newly-created product in Salesforce and checking its Product Description. In this case, it shows that the Product is updated successfully:
Conclusion – Using MuleSoft Composer for Salesforce and External Systems
This example is just one of thousands of use cases you could dream up. The goal is to get you thinking about integrating your different systems, reducing duplication of effort, and feeling confident that with MuleSoft and RPA, anything can be connected to your Salesforce org (or any other systems you might have in play).
While MuleSoft Composer for Salesforce is our preferred way, your situation might be more complex and you could require MuleSoft Anypoint. In either case, your data is within reach of multiple systems, safely, efficiently, and well-architected.
Check out the video presentation of this article:
Update External Data with Salesforce using MuleSoft Composer and RPA - YouTube
Tap to unmute
Update External Data with Salesforce using MuleSoft Composer and RPA CloudFirst Labs
CloudFirst Labs202 subscribers
Talk to the Professionals!
To learn more about our MuleSoft IDP, MuleSoft RPA, Partner Manager and EDI, or Salesforce services, please visit our website or fill out a Contact Us form here.
Getting Started – EDI is easy using MuleSoft Partner manager
This article details how to set up an FTP solution via Anypoint Partner Manager for receiving an X12 850 Purchase Order message from a trading partner. The configured message flow will receive the message in the X12 EDI format, convert it to JSON, FTP back an acknowledgment (997 Functional Ack), and then send the JSON to a Process API which can deliver the appropriate data to any relevant systems. and process it to those same systems.
Note that there will be several references to steps completed as part of a previous article implementing an AS2 “Receive from Partners” endpoint and message flow. The references to previously completed work demonstrate the power of Partner Manager because it allows these components to be reused for numerous trading partners and protocols.
Pre-requisite
A pre-requisite for completing the steps in this How-To article is having access to an FTP server.
Create New Message Flow
Open up MuleSoft Partner Manager in Anypoint and click Message Flows. Click “New message flow” -> “Receive from Partner”. This will open a new window asking which partner the message flow is for:
Create New Partner
From the “Select a partner” popup, click the New button. Enter the name (Other Company BCD). Then for Type, select Reference ID and enter an Identifier Value (OTHERBCD). Click Create Partner and Message Flow:
After this, add two additional identifiers to this partner. Go to Partners on the left-hand side and add two new Identifiers: one for “X12 – GS”, Identifer Value = OTHERBCD. For the other, set Type = “X12 – ISA”, Qualifier = ZZ, Identifier Value = OTHERBCD. This configures the partner as needed:
With this done, go back to the Message Flow.
Create New Endpoint
At this point, the Message Flow is created. The first step is to set up a new endpoint for receiving Purchase Order EDI messages. Click “Receive from Other Company BCD”:
Click Select Endpoint. It will show “No endpoint selected” under “Receiving endpoint”. Click the Select button. Click New. For protocol, select FTP.
Keep the owner as the name of the in-use organization (e.g. Cloud First Labs). Set the endpoint name as desired. Provide a meaningful description. For host, port, username, and password, enter the FTP login information for the prerequisite FTP location (Note that access to these FTP locations will be required to successfully work through this example.):
Scroll down to the Source path and enter /OtherBCD. Leave the polling frequency at 1 minute, meaning this location will be checked for new messages every 1 minute. For Support Format type, select EDI. Leave the size check wait time at 1 second, and for File name pattern, use *.edi. This is the file format the receiver will look for. For archival path, enter /OtherBCD/archive; this is where the source files will get moved to after intake for processing. Click Save:
With this saved, the endpoint is set up. Next, the Source Message must be configured.
Select Message Type
Click Source message and “No message type selected” should show up. Click the Select button. Click New to create a new message type. For Format, select X12. For Version, select 4010. For Message Type, select 850. (X12 850 messages are Purchase Order messages.) Leave the Reference identifiers and attributes mapping field blank, and for Schema, select “Use standard X12-4010-850”. Click Save:
Now the message type is set up. Leave the Validation settings as defaulted. This example’s next configuration is an Ackowledgement which will be automatically generated and dropped in the same FTP location to be picked up by Other Company BCD:
Configure the Acknowledgement
Under Acknowledgement, check the “Send 997 functional acknowledgement” box. Click Select to select the endpoint to deliver to. Click New to create a new endpoint.
Set Owner = Cloud First Labs, protocol = FTP. Set an endpoint name and description. For host, port, username, and password, use the FTP credentials from the prerequisite FTP location. For Target path, set “/OtherBCD/acks”. For Filename pattern, leave it as default. Click Save. This configures the flow to automatically generate a 997 acknowledgement for the sender’s consumption:
Configure the DWL Data Transformation
Click Map to open up the Map section. My previous AS2 EDI article has more detail on how this .dwl file is generated; in this example, the assumption is that this .dwl transformation file already exists on the local computer. Click Import. Find file ‘INB_PO_NTO_4010_850_to_Enterprise_PO_JSON.dwl’ ( from this example in Anypoint Exchange) and click Upload mapping:
With this done, the data transformation (from EDI to JSON) is set up and the final step remains to deliver the JSON to the Process API:
Configure the Target Endpoint
Click “Target at Cloud First Labs” and for message type, click Select. This example will reuse the JSON-purchase-order-2 message type that was created as part of this prior article. See that article for how this message type was originally configured. Select the Message type and click Select:
For endpoint, click Select. This example will once again take advantage of reuse and use the HTTPS-Inbound-Target-1 which was set up as part of the prior How-To article . Select the target and click Select:
Deploy the Message Flow
Upon doing the previous steps, the Message Flow is ready for deployment:
Click Deploy. Add whatever comment is appropriate, and click Deploy. A pop-up window will show up:
Test the Message Flow
Once the deployment is complete, test the flow by placing a file in your FTP input location (e.g. ftp.someftpserver.com/OtherBCD). The file should be a valid X12 850 message, such as the following:
ISA*00* *00* *ZZ*OTHERBCD *ZZ*CLOUDFIRSTLABS *200915*0103*U*00401*000000135*0*P*>~
GS*PO*OTHERBCD*CLOUDFIRSTLABS*20200915*0103*135*X*004010~
ST*850*0001~
BEG*00*NE*PO-DEMO-20200912-002**20191018~
REF*VR*7429271~
PER*BD*Tim Brown*EM*tbrown@nto.com~
PO1*1*20**34.45****MG*324791~
PID*F****8.5" x 11" Copy Paper, 20 lbs, 92 Brightness, 5000/Carton (324791)~
N1*ST*Salesforce West*92*338~
N3*50 Fremont St*Suite 1456~
N4*San Francisco*CA*94105*US~
PO1*2*80**1.95****MG*2072174~
PID*F****Hype Tank Highlighters, Chisel, Yellow, Dozen (29203)~
N1*ST*Salesforce East*92*367~
N3*350 Mission St*Floor 5~
N4*San Francisco*CA*94105*US~
PO1*3*65**5.08****MG*163865~
PID*F****Notepads, 8.5" x 11.75", Wide Ruled, White, 50 Sheets/Pad, 12 Pads/Pack (51295/2~
N1*ST*Salesforce Tower*92*587~
N3*415 Mission St*Floor 3~
N4*San Francisco*CA*94105*US~
PO1*4*30*PH*11.77****MG*467951~
PID*F****Lightweight Moving & Storage Packing Tape, 1.88"W x 54.6 Yards, Clear, 6 Rolls (~
N1*ST*Tableau Palo Alto*92*1564~
N3*260 California Ave*Ste 300~
N4*Palo Alto*CA*94306*US~
CTT*4~
SE*26*0001~
GE*1*135~
IEA*1*000000135~
Save the file as FileFromBCDtoCFL.edi and place it in the FTP location for receiving from the partner (e.g. ftp.someftpserver.com/OtherBCD):
Within one minute, the FTP listener configured above should pick up the message and process it. After it picks it up, view the Activity screen in Partner Manager. It should show the message in Delivered status:
Click into the message and more details are available (including payloads which can be clicked on for inspection:
Finally, check the FTP location under /OtherBCD/acks to see the 997 functional acknowledgment which was generated:
This shows that processing was successful all the entire way through(the image is really small, but trust us!).
Conclusion
With the steps carried out in this article, a successful FTP EDI setup can be put in place thanks to the Mulesoft Partner Manager functionality in Anypoint. It can be expanded on as well, allowing easy configuration to set up multiple trading partners, message types, and protocols. As with most types of integration, MuleSoft Partner Manager makes business to business EDI integration straightforward. For a guided tour of getting this set up, check out my YouTube video:
Use FTP via MuleSoft to Transmit B2B EDI in Partner Manager - YouTube
Tap to unmute
Use FTP via MuleSoft to Transmit B2B EDI in Partner Manager CloudFirst Labs
CloudFirst Labs202 subscribers
Talk to the Professionals!
To learn more about our MuleSoft RPA, MuleSoft Partner Manager and EDI, or Salesforce services, please visit our website or fill out a Contact Us form here.
Overview – Sending AS2 EDI in MuleSoft
Anypoint Partner Manager is a great product for enabling the straightforward setup of an organization’s B2B environment. It allows for easily dealing with a myriad of partner-specific configurations, message types, and protocols. Partner Manager supports data transfer via HTTP, FTP, and AS2. This article and accompanying video walk through how to set up a new partner integration for a partner (“New Partner XYZ”) sending X12 850 Purchase Orders to an organization (“Cloud First Labs”) via AS2. A diagram showing the approach is below [Note that in this example, there are other partners already configured to send EDI data to the organization via HTTP and FTP.] :
Create Private Keys and Public Certificates
AS2 requires mutual authentication, meaning the receiver and sender must each generate their own private key and public certificate. The sender must send the sender’s public certificate and the receiver must trust that sender public cert. The receiver must provide the sender with a public certificate and the sender must trust that receiver public cert.
In the real world, these private keys and certificates will be generated by Security teams from the two trading partner organizations, and the certificates will likely be signed by certificate authorities per organizational standards. However, to demonstrate the Partner Manager AS2 capability end-to-end, this example will generate self-signed certificates.
To generate a private key (cloudfirstlabs_private_key.key) and certificate (cloudfirstlabs_public_cert.cer) for the receiver, run the following command in Git Bash:
winpty openssl req -newkey rsa:2048 -keyout cloudfirstlabs_private_key.key -x509 -days 365 -out cloudfirstlabs_public_cert.cer
(At prompts, use Cloud-First-Labs-specific information, and make sure to remember the password used.)
winpty openssl req -newkey rsa:2048 -keyout newpartnerxyz_private_key.key -x509 -days 365 -out newpartnerxyz_public_cert.cer
(At prompts, use New-Partner-XYZ-specific information, and make sure to remember the password used.)
These private keys and certificates will be used later.
Partner Manager: Create Partner
Log in to Partner Manager. Click Partners. Click Create partner. Enter the name (New Partner XYZ) and create the identifier as Type = “AS2 identity” and Identifier Value = “newpartnerxyz”. Then click New under Identifiers to add a new “X12 – GS” identifier with value “NEWPARTNERXYZ”. Then click New one more time to add a new “X12 – ISA” identifier with value “NEWPARTNERXYZ” and Qualifier “ZZ”.
This configures the new trading partner in Partner Manager.
Partner Manager: Create New Message Flow
Click “Message Flows” in Partner Manager and click “New message flow”. Select “Receive from partner”. Select New Partner XYZ as the partner to configure the flow for.
Create New AS2 Endpoint
Click “Receiving endpoint” in the newly created Message Flow. Create a new one, and use Protcol = AS2. Name the endpoint with a meaningful name. Uncheck “Private port”. Leave HTTPS checked and leave Enforce security level as “Signed & Encrypted”:
In the Keystore section, click Select to select a keystore. Then click New to create a new one. Choose the cloudfirstlabs_public_cert.cer file created in a previous section for the public certificate, and select the cloudfirstlabs_privatekey_key.key file created in previous section for the private key file. Then enter the password for the private key and click Create:
This successfully creates the keystore. After it is created, click Save to save the new AS2 endpoint.
Add certificate for New Partner XYZ
Below the “Receiving endpoint” section, it prompts for a certificate for New Partner XYZ. Add one, of type Public Certificate, and upload the newpartnerxyz_public_cert.cer file created in a previous section. Click Create:
Add a new Message Type
With the certificate added, the next step is to add the Source message’s Message Type. Click Source message and then choose Select to select a Message Type. Then click New to create a new Message Type. This example uses the standard X12 version 4010 850 Purchase Order message, so select Format = X12, Version = 4010, Message type = 850, leave the mapping file blank, and set Schema = “Use standard X12-4010-850” and click Save:
Select the newly-created message type. Settings could be modified and a functional ack could be configured here, but for simplicity’s sake, this example leaves the Validation settings as the default and leaves the 997 functional acknowledgement checkbox unchecked.
Add DataWeave mapping file
The next configuration to provide is the DataWeave mapping file.
Click Map and see that an Import button shows up. Before importing, this file needs to be available on the local computer. In the real world, this will be a carefully developed DataWeave transformation file developed in accordance with the requirements. In this example case, an X12 850 message needs to get converted to PurchaseOrder JSON to be sent on to a Process API. This example in Anypoint Exchange can be downloaded and the INB_PO_NTO_4010_850_to_Enterprise_PO_JSON.dwl file from within that example can be used for this purpose. Download the example. Then click Import and import the .dwl file.
This is the transformation that will be applied to the incoming X12 message.
Configure the Target
Configure the Target Message Type
The next step is to open up the Target at Cloud First Labs section and select a Message Type. Click New to create a new Message Type. Select Format = JSON. For Schema, create a file on the local computer named PurchaseOrder2.schema and have it contain a simple empty JSON object: {}. This simple JSON schema will permit any valid JSON. In a real world scenario, this JSON schema would be a real JSON schema defining what the Process API JSON message should contain, but for simplicity’s sake this example permits any JSON to flow through. Click Choose file and select PurchaseOrder2.schema and click Save.
Configure the Target Endpoint
With the target message type in place, the next step is to set up the target endpoint:
In the real world, this will point at a Process API used to handle messages and deliver data to target systems, and the Process API will require authentication. In this case, the configured endpoint is a simple API (cfl-example-200-api) deployed to CloudHub 2.0 which simply logs the message and returns a 200 OK response, and it does not require authentication.
Configure an appropriate URL and select None for Authentication type and click Save:
At this point, the message flow is fully configured and ready for deployment:
Partner Manager: Deploy Message Flow
Click Deploy to deploy the Message Flow and enter comments. It will take a few minutes to deploy. Under the hood, the deployment was deploying applications to Anypoint Platform. They are visible in Runtime Manager. The AS2 receiver is deployed as an application named b2b-inbound-as2-
Now that the message flow and its corresponding applications are deployed, a simple locally-running Mule application can be used to send an AS2 message to the AS2 endpoint that was just deployed in Partner Manager.
Anypoint Studio: Create Client App to Test AS2 Endpoint
Open up Anypoint Studio. Create a new Mule project and add a basic HTTP Listener on port 8081 at path /as2. In the Mule Palette, double-click “Search in Exchange” and search for AS2. Add “AS2 Connector” to Selected modules and click Finish. This enables use of the AS2 Connector in the Mule application.
From the Palette, select AS2 Connector and drag Send with Sync MDN to the flow on the HTTP Listener:
Configure the “Send with Sync MDN” component to use AS2 MIME Type = “application/edi-x12” and let it use payload for the Content Stream. Leave the rest of the values default except for the Connector configuration:
For the Connector configuration, add a new one and configure a Partner URL =
Configure that into the Partner URL field:
Next, go to the Security tab. Scroll down to the Self Config and Partner Config section of the Security tab. For this, the AS2 Partner names must be set in accordance with what was configured inside Partner Manager. So AS2 Partner Name for Self Config is “newpartnerxyz” and AS2 Partner Name for Partner Config is “cloudfirstlabs”. This is because this sending Mule app is demonstrating sending from New Partner XYZ to Cloud First Labs.
For x509 Alias, the alias to use is dependent on a keystore file which still needs to be generated. Earlier in this article, private keys and public certificates were generated for New Partner XYZ and Cloud First Labs. The private key for New Partner XYZ and the public certificate for Cloud First Labs should be put into a P12 keystore, and the aliases from that P12 keystore should be entered here. Run the following command to generate a new P12 keystore with the New Partner XYZ private key stored inside it.
winpty openssl pkcs12 -export -in newpartnerxyz_public_cert.cer -inkey newpartnerxyz_private_key.key -out newpartnerxyz.p12 -name newpartnerxyz -CAfile ca.crt -caname root
Note that the name (alias) of the private key is “newpartnerxyz”. Also make note of the export password entered here. The alias and keystore password will be used in the AS2 Connector Send configuration.
Then, import the Cloud First Labs public certificate into the same keystore with the following command.
keytool -import -alias cloudfirstlabs -keystore newpartnerxyz.p12 -file cloudfirstlabs_public_cert.cer
Note that the alias here is “cloudfirstlabs”.
Add the P12 keystore file newpartnerxyz.p12 into src/main/resources of this Mule application.
Back in the AS2 Connector Send config window in Anypoint Studio, on the General -> Security tab, configure the Self Config and Partner Config with the alias names just noted above. And for the email address, use the email address configured originally into the prompts for the private keys/certificates generated via openssl commands:
Scroll down and the next configuration is for Requester Config. Enter whatever subject is desired to be sent with the EDI messages to the AS2 Receive from Partners endpoint. Leave the rest of the Requester Config fields as the default values:
In the Keystore Config section, configure the keystore path as newpartnerxyz.p12 (which it will find since the file is now in src/main/resources in the project). And for keystore password and private key password, enter the password entered for the P12 file generation earlier:
Click OK to save the configuration. With this in place, deploy the application. Once it starts up, the next step is to send an X12 850 (Purchase Order) request to the locally-deployed endpoint, which will use the AS2 Connector to send an AS2 request to the Cloud First Labs AS2 Receive From Partners endpoint (which was configured earlier in Partner Manager).
Test Client App and AS2 Endpoint
Once the application has deployed locally, open up Postman and send the following request (or another valid X12 850 request) to http://localhost:8081/as2.
ISA*00* *00* *ZZ*NEWPARTNERXYZ *ZZ*CLOUDFIRSTLABS *200915*0103*U*00401*000000133*0*P*>~
GS*PO*NEWPARTNERXYZ*CLOUDFIRSTLABS*20200915*0103*133*X*004010~
ST*850*0001~
BEG*00*NE*PO-DEMO-20200912-002**20191018~
REF*VR*7429271~
PER*BD*Tim Brown*EM*tbrown@nto.com~
PO1*1*20**34.45****MG*324791~
PID*F****8.5" x 11" Copy Paper, 20 lbs, 92 Brightness, 5000/Carton (324791)~
N1*ST*Salesforce West*92*338~
N3*50 Fremont St*Suite 1456~
N4*San Francisco*CA*94105*US~
PO1*2*80**1.95****MG*2072174~
PID*F****Hype Tank Highlighters, Chisel, Yellow, Dozen (29203)~
N1*ST*Salesforce East*92*367~
N3*350 Mission St*Floor 5~
N4*San Francisco*CA*94105*US~
PO1*3*65**5.08****MG*163865~
PID*F****Notepads, 8.5" x 11.75", Wide Ruled, White, 50 Sheets/Pad, 12 Pads/Pack (51295/2~
N1*ST*Salesforce Tower*92*587~
N3*415 Mission St*Floor 3~
N4*San Francisco*CA*94105*US~
PO1*4*30*PH*11.77****MG*467951~
PID*F****Lightweight Moving & Storage Packing Tape, 1.88"W x 54.6 Yards, Clear, 6 Rolls (~
N1*ST*Tableau Palo Alto*92*1564~
N3*260 California Ave*Ste 300~
N4*Palo Alto*CA*94306*US~
CTT*4~
SE*26*0001~
GE*1*133~
IEA*1*000000133~
This should return a 200 OK status and there should be some output in the response body:
After seeing it there, go to Partner Manager -> Activity and look for recent activity. It should show up there as well:
Upon clicking into it, there is an option to even see the source payload and the target payload.
Source payload:
Target payload:
The logs of the target endpoint can also be checked (cfl-example-200-api in this example) and the JSON payload shows up in the logs (which in turn could be used for processing and orchestration to any and all required systems thanks to MuleSoft’s well-honed integration capabilities):
Conclusion
With the steps included in this article, a team can set up its own AS2 B2B endpoint for working with a trading partner. Partner Manager makes it easy to configure many partners, message types, and protocols. As shown here, Partner Manager gives plentiful options for configuring connections between disparate systems and makes setting up a complex environment simple and straightforward. For a guided tour of getting this set up, check out my YouTube video:
Use AS2 to Transmit B2B EDI in MuleSoft Partner Manager - YouTube
Tap to unmute
Use AS2 to Transmit B2B EDI in MuleSoft Partner Manager CloudFirst Labs
CloudFirst Labs202 subscribers
Talk to the Professionals!
To learn more about our MuleSoft RPA, MuleSoft and EDI, or Salesforce services, please visit our website or fill out a Contact Us form here.
Overview – Using an Alternate to the MuleSoft Sharepoint Connector
In several of my previous blog posts ( RPA Introduction, Iterate over HTML, Web Form Filling, and others), we learned that the MuleSoft RPA processes can be used to handle a plethora of use cases and these processes can be triggered from all sorts of common applications. This post shows how easily a MuleSoft RPA process can be used to work with Sharepoint data. The use case kicks off a published RPA process, triggered by the creation or upload of a new file in a specific Sharepoint folder. The RPA process receives the name of the file, downloads the file, parses the data, and uses the parsed data to do swivel-chair operations updating another application (Salesforce). Whereas Part 1 focused on the Sharepoint side of this integration, this Part 2 post focuses on the MuleSoft RPA Builder side. Follow along as we show you this alternate method of getting things done without using the MuleSoft Sharepoint Connector
This use case implementation has 4 workflows:
- Download a CSV from Sharepoint
- Log in to Salesforce
- Create a Quote from CSV
- Add Products to the Quote
The key aspects this post will focus on are:
- Downloading the file from Sharepoint without logging in to Sharepoint at each RPA process run
- Find the downloaded file
- Parse useful data from the downloaded file
Important Callout
It is important to note that this setup is not the only way to integrate with Sharepoint; this is to specifically show how to directly integrate Sharepoint with a MuleSoft RPA process. However, for organizations with Anypoint Platform subscriptions, a MuleSoft application can be used to easily monitor and/or integrate with Sharepoint using the robust MuleSoft Sharepoint Connector. The connector has dozens of operations available to handle Sharepoint integration needs, and MuleSoft’s integration platform enables all sorts of processing and orchestration options.
Key Aspects of MuleSoft RPA Sharepoint Integration
How to Download Sharepoint File without Login
This use case shows how to configure the RPA process to download the file from Sharepoint without logging into Sharepoint at each run. To do this, manually log into the PC/VM as the Windows user that the RPA bot runs as. With that user, open Chrome and log into Sharepoint. Ensure that the login persists; close Chrome and reopen and make sure it is still logged in to Sharepoint. If it is, that login info is stored in that user’s Chrome user data. With that in place, open the Chrome Web Session configuration and add an “Additional argument”. Set –user-data-dir=C:\Users\%USERNAME%\AppData\Local\Google\Chrome\User Data. This will have the RPA process use the bot user’s Chrome user data which will include the Sharepoint login. This will save the RPA developer from needing to configure the RPA process to log in to Sharepoint each time the process runs:
How to Find Downloaded File
After the process navigates to the URL (
How to Parse the Data from Downloaded File
To parse the data from the file, get the number of lines in the file. Loop over those lines one by one, and convert each CSV line into an array of values (e.g. productName and listPrice in the example screenshot). These values can be used in later steps to do data entry into the target system:
Putting the Alternate Method to Using the MuleSoft Sharepoint Connector All Together
To see this in action, and learn more details about this alternate method to the MuleSoft Sharepoint Connector, check out the video that goes along with this post:
Integrate Sharepoint with MuleSoft RPA Part 2 - YouTube
Tap to unmute
Integrate Sharepoint with MuleSoft RPA Part 2 CloudFirst Labs
CloudFirst Labs202 subscribers
After reading the blogs and watching the videos, it will be clear how straightforward it is to automate Sharepoint interactions with other organizational applications using MuleSoft RPA.
Talk to the Professionals!
Overview
So why would you want to integrate with Gmail API using Mulesoft? Several use cases exist, ranging from processing a Gmail inbox for attachments to sending emails from a process outside of Salesforce. Since Gmail offers many APIs for handling email-related operations, and MuleSoft is positioned well to integrate with these APIs, there are many more possibilities, but this article will focus on sending an email with an attachment. There is abundant documentation about Gmail APIs available from Google but it is challenging to parse and get immediately-usable information from the documentation. Because of that, this post is here to fill in the gaps and show how to use MuleSoft to integrate successfully with Gmail APIs. As detailed in the sections below, some of the key steps for MuleSoft/Gmail integration are:
- Set up a Google Account
- Download Gmail Connector from Anypoint Exchange
- Set up the OAuth 2.0 Authorization Code flow in the Mule application
- Generate the proper payload
- Deploy the application with the correct settings
Follow along as I show you how to integrate with Gmail API using Mulesoft.
Set Up a Google Account
To utilize Gmail APIs, the first step is to set up the related Google accounts by logging in to a Google account and going to console.cloud.google.com.
Create Billing Account
To connect to the Gmail APIs, a project is required, and a billing account is required to create a project. From console.cloud.google.com, go to the hamburger menu -> Billing and click “Add Billing Account”. Follow the directions there to set up the account; of course, be careful with the setup of this project and how many requests use this billing account to avoid running up charges.
Create a New Project and Enable Gmail API
On the home page for console.cloud.google.com, click the dropdown menu at the top and when the screen pops up, click “New Project”. Give the project a name and use the billing account created in the previous step. Click Create.
Within that project, click the hamburger menu -> APIs & Services. From this screen, click “Enable APIs and Services” and find Gmail API within the API library screen that pops up. Click on this Gmail API and click Enable to enable the Gmail API for this project.
Configure the Gmail API for this Project
With the Gmail API now enabled for this project, it must be configured appropriately. To start, click Create Credentials:
For Credential Type, select User data and click Next:
Enter a name for the application and the email address that will be provided for support. (These will be displayed to the user who authorizes the rights to use the Gmail API). Add a developer contact email address as well and click Save and Continue:
Under Scopes, click Add or Remove Scopes. Add the Gmail API scope for “…/auth/gmail.modify” to allow for reading, composing, and sending emails from the Gmail account. Click Update, then click Save and Continue:
For the OAuth Client ID, select Web Application for Application type and give a name (e.g. “Mule OAuth Demo Client”). Add an Authorized Redirect URI of http://localhost:8081/callback. This section will be revisited later upon deployment to CloudHub 2.0 to add the CloudHub 2.0 API callback URL. Click Create:
After clicking Create, the client credentials (client ID and client secret) are generated and available for download as a JSON file. Download this file as the client ID and secret will be needed later. [This JSON file also contains the Auth URL and the Token URL which will be used later.]. Click Done.
At this point, only one thing remains te be able to test out the API. With the Google project in a Testing status, simply add test users. Only specified Google accounts will be able to use the credentials just created in order to call the Gmail API. Therefore, test users must be added. From the project’s main page -> APIs & Services -> OAuth consent screen, click the Add Users button:
Add the email address(es) that will be using the Mule-to-Gmail application and click Save:
With this in place, the Google setup is complete, and that Gmail account is now configured inside the MuleSoft application to call Gmail APIs.
Download Gmail Connector from Anypoint Exchange
Create a new project in Anypoint Studio. In the Mule Palette, click Search in Exchange. search for “Gmail”. Select the “Gmail Connector” and click Add:
After this step has been performed, in the Mule Palette you will see dozens of Gmail components available to be added to the MuleSoft application. For this example, we will use the Send Message component:
Set Up OAuth 2.0 Authorization Code Flow
How OAuth 2.0 Authorization Code flow Works
The OAuth 2.0 Authorization Code flow is a standard commonly used throughout the technology industry. It involves a manual step to grant/authorize access and then upon that authorization, an authorization code is provided back to the user. The authorization code is then combined with the client ID and client secret to get an access token, and the access token is what is used as the authorization for the actual API calls. A good intro to this is found in this documentation from oauth.net. Mulesoft also has some of its own useful documentation here.
How to Configure Authorization Code Flow in Mule Application
Within a new Mule application in Anypoint Studio, create an HTTP Listener to receive messages to the /email endpoint. Assume for the time being that the payload is set up for the send to the Gmail API (this will be handled later in this post). Add a Send Message component to the flow. In the Send Message component, configure User Id as the email address to be used to send the email (e.g. joecfltesting@gmail.com). [Note that this email address is the one that will have to provide authorization to use the Gmail API in the OAuth 2.0 authorization code flow.] Then click the green plus button to configure a new Gmail Connector configuration:
The Consumer key, Consumer secret, Authorization URL, and Access token url field values are all available from the JSON file downloaded in steps earlier from the configuration within the Google console. For scopes, enter https://www.googleapis.com/auth/gmail.modify to match what was configured within the Google console in those earlier steps:
Scroll down to the oauthCallbackConfig section. For the Listener config, select the same HTTP Listener that is in place for the application’s /email endpoint. For the Callback path, configure “callback”. In the Authorize path, configure “authorize”. In the External callback url, configure a property value: ${app.callback.url}. This value will get set as http://localhost:8081/callback when running locally; when deploying to CloudHub 2.0 in later steps, this app.callback.url property will get set in the Properties section of Runtime Manager for the deployed application:
Scroll down to the oauthStoreConfig section. Click the green Plus symbol to create a new Object store configuration. [Note: If the green Plus button doesn’t open anything, try going to the main flow and adding an Object Store component to the flow and then deleting that component. This will bring the Object Store connector dependency into the application, which is required to create the Object store configuration.]
Name this Object store “OAuth_object_store” and make sure Persistent is checked. [Setting it as “Persistent” is important for deployment to CloudHub 2.0 because it will use Object Store v2 which will allow the authorization to last between deployments. Without setting this to persistent, a user has to reauthorize the app to use Gmail API at each re-deployment.] Click OK, and click OK again to save the Gmail Connector configuration:
With this in place, the Gmail Connector is configured for use (including its OAuth setup), and it is time to set the actual payload to send to the Gmail API.
Generate Proper Payload for Sending Mail
The next step is to actually set the payload for the Gmail Send Message component. The basic example will send an email with attachments based on the input payload. The written version of this example will show how to do this using DataWeave, but the accompanying video shows DataWeave and an alternative option: a static Java class.
The Gmail API documentation is challenging to grasp as far as what exactly should go into the payload request to the Gmail API. Ultimately, an RFC 2822 compliant payload should be sent, base64-encoded, to the Gmail API.
The following assumes that an input request comes to MuleSoft like this:
``
{
"fromEmail": "joecfltesting@gmail.com",
"toEmails": ["joe.kalb@cloudfirstlabs.com"],
"subject": "Sample HTML email with attachment",
"emailBody": "<html><h1>Joe was here</h1><h2>Header2</h2>Here is some normal text. And here is a <a href=\"https://www.cloudfirstlabs.com\">link</a></html>",
"attachments": [\
{\
"fileName": "someText.txt",\
"contentType": "text/plain",\
"base64Content": "SGVyZSBpcyBzb21lIHRleHQgaW4gYSB0eHQgZmlsZQ=="\
}\
]
}
The following DataWeave Transform should be placed upon reception of this payload. Assign the output to a variable named rawEmail.
%dw 2.0
import java!java::lang::System
var toEmailString = (payload.toEmails reduce(item,accum="") -> (accum ++ if (accum == "") item else "; " ++ item))
output text/plain
---
'Content-Type: multipart/mixed; boundary=bndry_sprtr' ++ System::lineSeparator() ++
'MIME-Version: 1.0' ++ System::lineSeparator() ++
'From: ' ++ payload.fromEmail ++ System::lineSeparator() ++
'To: ' ++ toEmailString ++ System::lineSeparator() ++
'Subject: ' ++ payload.subject ++ System::lineSeparator() ++
System::lineSeparator() ++
'--bndry_sprtr' ++ System::lineSeparator() ++
'Content-Type: text/html' ++ System::lineSeparator() ++
'MIME-Version: 1.0' ++ System::lineSeparator() ++
'Content-Transfer-Encoding: 7bit' ++ System::lineSeparator() ++
System::lineSeparator() ++
payload.emailBody ++ System::lineSeparator() ++
System::lineSeparator() ++
((payload.attachments reduce (item, accumulator="") -> (
accumulator ++
'--bndry_sprtr' ++ System::lineSeparator() ++
'Content-Type: ' ++ item.contentType ++ System::lineSeparator() ++
'MIME-Version: 1.0' ++ System::lineSeparator() ++
'Content-Transfer-Encoding: base64' ++ System::lineSeparator() ++
'Content-Disposition: attachment; filename="' ++ item.fileName ++ '"' ++
System::lineSeparator() ++
System::lineSeparator() ++
item.base64Content ++ System::lineSeparator() ++
System::lineSeparator())) default '')
++ '--bndry_sprtr--'
It is beyond the scope of this article to detail each part of the DataWeave, but know that it is transforming the input payload to an RFC 2822-compliant email message. Then in the follow-up step, that raw RFC 2822 message should be base64-encoded and passed in the raw field of a JSON output payload. To handle this, add one additional DataWeave transform step with the following transform:
%dw 2.0
import java!java::lang::System
import * from dw::core::Binaries
output application/json
---
{
raw: toBase64(vars.rawEmail)
}
Put these two transforms back to back before the Gmail Send Messages component and the basic application is ready to test locally. With the above example payload (changed to use relevant email addresses), the running Mule application should successfully send an email with attachment(s) using the Gmail API:
Test the Application Locally
To test the application locally, the first step is to set the app.callback.url property. Right-click the application in Package Explorer -> Debug As -> Debug Configurations. Then go to the Environment tab. Add an entry for app.callback.url and a value of http://localhost:8081/callback:
Now that this is set, the application is ready to deploy locally. Go to Package Explorer -> Debug As -> Mule Application to run the application. It should start successfully.
Before a request can be made to the local API, a user must authorize the application. To do this, visit http://localhost:8081/authorize. This will have the user log in to a Gmail account and grant access. At the end of this, the user should see a screen that says “Successfully retrieved access token”. The authorization code is found in the browser bar after the callback URL configured in the app (e.g. http://localhost:8081/callback). [Note: This is the reason http://localhost:8081/callback had to be added as a redirect URI in the Google console setup.]
Under the covers, MuleSoft uses that authorization code, along with the configured client ID and client secret, to get an access token for any calls to the Gmail API. [The access token and any and all refreshing is handled under the covers as well by MuleSoft using the object store configuration set up earlier.] Regardless, with this completed, the application is now ready to run and successfully make requests to the Gmail API. From Postman (or the application of choice), POST the payload mentioned a few sections above into an HTTP request to http://localhost:8081/email :
A 200 status should be returned with a SENT in the response payload. And the email should show up in the inbox(es) configured in the payload:
When you reach this step it is ready to be deployed into CloudHub 2.0.
Deploy Application with Proper Settings
It is beyond the scope of this post to detail every step of deployment to CloudHub 2.0, but there are a few key ideas that should be highlighted.
- The application should run in Runtime Cluster Mode in CloudHub 2.0.
- The application should run with Object Store v2 configured.
- The URL generated by Anypoint upon deployment must be configured in the Google setup to allow the callback URL to be called as part of the OAuth 2.0 Authorization Code flow.
- The app.callback.url property must be configured with the Anypoint-generated URL to set the callback URL when authorizing the application to use Gmail API.
Key Idea: Run Application in Runtime Cluster Mode
When running in Runtime Manager with 2 or more replicas, run in Runtime Cluster Mode. This is to support the successful setup of the OAuth 2.0 Authorization Code flow. When running as a cluster, the multiple replicas share memory and therefore share the authorization code provided back at the end of the manual authorization step upon initial deployment. Without running in cluster mode, every single replica must individually run the authorization step:
Key Idea: Configure Object Store V2
Run this application using Object Store V2. This enables the object store to survive redeployments, keeping a user from needing to reauthorize the application every time the application redeploys:
Key Idea: Configure CloudHub URL into Redirect URIs in Google
After the application attempts to deploy initially, it should provide a public endpoint. Use this and append /callback (e.g. https://cfl-example-gmail-sapi-8kbpti.pm4uy8.usa-e2.cloudhub.io/callback) and configure the value into the Google setup as a Redirect URI. (Do this from Google Console -> project -> APIs & Services -> Credentials -> the specific OAuth 2.0 Client ID -> Add URI) :
Key Idea: Set the app.callback.url Runtime Property
In the Properties tab of Runtime Manager for this application, set app.callback.url equal to the CloudHub URL. This should hold the same value as entered into the Authorized redirect URIs in the Google console. Apply Changes to re-deploy the app to CloudHub 2.0 with this property set. Upon redeployment, the application should be ready to run, to manually do the authorization step, and then to integrate successfully with the Gmail API.
That’s all there is to integrate with Gmail API using Mulesoft!
By doing the steps above, this API should deploy successfully to CloudHub 2.0 and be ready to integrate with Gmail. While I do not show a specific use case, the power of MuleSoft for integrating and orchestrating between numerous systems is obvious. This template can easily be applied to other business processes or APIs, not just Gmail.
A walk-through video demonstration of the steps I took to integrate with Gmail API using Mulesoft can be found here on our YouTube channel:
Integrate Gmail APIs with MuleSoft - YouTube
Tap to unmute
Integrate Gmail APIs with MuleSoft CloudFirst Labs
CloudFirst Labs202 subscribers
Talk to the Professionals!
Overview – Web Form Filling Using MuleSoft RPA (Part 2)
We’re all here reading this post because we know that MuleSoft RPA is a great tool for the automation of basic Web tasks, such as filling out forms. This example shows how Salesforce can provide data to a MuleSoft RPA process to fill in a Web form, and Salesforce gets updated with output data from the RPA process. Salesforce and MuleSoft RPA work together effortlessly for a smoothly integrated automation experience.
Prerequisites for Web Form Filling Using MuleSoft RPA
The following pre-requisites are needed for this example:
- Licenses for Salesforce and MuleSoft RPA
- Anypoint Platform credentials
- Salesforce credentials
- A MuleSoft RPA process in Production phase with an invokable run configuration*
- URL of this invokable RPA
- Client ID and Client Secret for Connected App with “RPA Invocable Process” scope
*For assistance with any part of this pre-requisite, please see Part 1 of this blog post and/or Cloud First Labs’ prior blog posts on invoking a MuleSoft RPA process via Postman:
Invoke a MuleSoft RPA Process via HTTP and Postman – Part 1
Invoke a MuleSoft RPA Process via HTTP and Postman – Part 2
Salesforce – Set up MuleSoft Services
MuleSoft Services must be set up for Salesforce to properly connect to the MuleSoft RPA process. To handle this, log in to Salesforce and go to Setup -> MuleSoft -> Services:
Log in, using Anypoint Platform credentials, to MuleSoft Anypoint Platform and grant access. Under the covers, this creates an external credential, a named credential, and an auth provider in Salesforce, all named “MuleSoft Anypoint Platform US”. This also automatically creates a “MuleSoft Anypoint Platform” permission set. This example will require setting up a separate external credential, named credential, and permission set, as shown in the steps below.
Salesforce – Create External Credential
Go to Setup -> Security -> Named Credentials. From there, go to the External Credentials tab. Click New:
In the New External Credential window, provide a Label and Name for this External Credential (e.g. “RPAWebFormExternalCredential”) and select OAuth 2.0 as the Authentication Protocol. Authentication Flow Type gets set to Client Credentials with Client Secret Flow, and Identity Provider URL gets set to the OAuth2 token URL used by the RPA process (e.g. https://anypoint.mulesoft.com/accounts/api/v2/oauth2/token). Click Save:
Next, a Principal needs to be created within this External Credential. From the main screen for the External Credential, scroll down to the Principals section and click New.
Fill in a name for the Principal and then enter the Client ID and Client Secret for the related Connected App (mentioned in the Prerequisites section above). This provides the External Credential with the actual credentials it needs to invoke the RPA process. Click Save:
Salesforce – Create Named Credential
With the External Credential in place, it now must be associated with a Named Credential. Go to Setup -> Security -> Named Credentials. Go to the Named Credentials tab and click New.
On this screen, enter a label and name, and then for the URL field, use the base URL for the relevant organization’s RPA processes. (For example, the Cloud First Labs’ RPA URL is https://cloud-first-labs.rpa.mulesoft.com). Ensure that the Enabled for Callouts is checked. For External Credential, select the External Credential created in the “Salesforce – Create External Credential” section above. Ensure that Allow Formulas in HTTP Body is checked and click Save:
Salesforce – Create Permission Set
Next, create a Permission Set by going to Setup -> Services -> Permission Sets -> New. For this exercise, name the Permission Set “RPA API Access”. Click Save:
Within that permission set’s page, go to the Apps section and click External Credential Principal Access:
Within this, go to Edit. Then add the RPA External Credential Principals:
Then click Manage Assignments and assign that permission set to someone with lots of access (such as a System Administrator). In my case, I assigned the permission set to my user (“Joe Kalb”) who is a System Administrator.
Salesforce – Create External Service for RPA Invocation
Next, an External Service must be created to invoke the RPA process. Go to Setup -> MuleSoft -> Services. Make sure the system is still logged in to Anypoint Platform. Then click Import. In the Import Service screen, find the name of the relevant RPA process (e.g. “Fill Out Web Form”):
Click Next, give a name, and then reference the previously created Named Credential and click Next:
The next page is “Select Operations to Import”. Here, select 2 operations: “startProcessV2” and “getProcessesExecutionStatusV2”:
The startProcessV2 operation is used to kick off the process and the getProcessesExecutionStatusV2 is used to get the details of the kicked-off process (e.g. get the process success/failure status and the values of the RPA’s activity parameters).
Click Finish.
With this in place, this service can be referenced as an External Service from a Salesforce Flow:
Salesforce – Create Flow to Kick off the RPA Process
Create a Flow
Go to Setup -> Process Automation -> Flows -> and click “New Flow”:
This example will execute when a Quote object gets its Status changed to Presented. For this reason, this example will be a Record-Triggered Flow, with two branches.
The first will be a “Run Asynchronously” path which will be kicked off immediately upon the record update, and it will do an external callout to invoke the RPA process using data from the triggering Salesforce object. (Note: the path must be a “Run Asynchronously” path instead of a “Run Immediately” path because external callouts cannot run from within a “Run Immediately” path in a Salesforce flow.) The second will run 2 minutes later to check on the status and details of the triggered RPA process execution, and it will update the Salesforce object with that RPA output data.
The example case kicks off the RPA process whenever a Quote object enters Presented status, so the flow configuration is set up as follows.
Trigger the Flow When: A record is updated
Condition Requirements = All Conditions Are Met (AND)
The Condition is: Status Equals Presented
When to run the Flow for Updated Records = Only when a record is updated to meet the condition requirements
Optimize the Flow for = Actions and Related Records
Check the “Include a Run Asynchronously path to access an external system after the original transaction for the triggering record is successfully committed” box:
With this configured, click Save and name the Flow (e.g. “RPA Web Form Flow”:
Implement “Run Asynchronously” Path
Add a New Resource for RPA Invocation HTTP Request Body
This flow path will be used to invoke the RPA process, and the invocation will happen via HTTP call. The flow will set the HTTP request payload for that invocation (using data from the triggering object). For this purpose, a new variable is created.
Expand the Toolbox and click New Resource. Resource Type = Variable. Set API Name = RPAInputBody. For Data Type, select Apex-Defined. In Apex Class, search for the name of the External Service created earlier (e.g. “FillOutWebForm100”) because that is how the auto-generated Apex classes are named. Find the class ending in “ProcessExecutionWithExecutionID”. This is what holds the input payload to the RPA process (e.g. “ExternalService__FillOutWebForm100_ProcessExecutionWithExecutionID”):
Add Assignment Element to Populate RPA Input Body
The RPAInputBody variable was created in the last step but not initialized with a value. To assign it a value, add a new step to the “Run Asynchronously” path. This step will be an Assignment. Set the Label = ‘SetRPAInput’ and then go down to the Set Variable Values section.
Set the RPAInputBody > executionId Equal to a relevant value that will serve as the unique identifier of the RPA process (e.g. $Record > Quote Number). This will be used later to check on the status of the executed RPA process.
The inputArguments will differ based on what the activity parameters are within the specific RPA process being invoked. In this instance, these values get set approximately as follows.
| Variable | Operator | Value |
| RPAInputBody > executionId | Equals | {!$Record.QuoteNumber} |
| RPAInputBody > inputArguments > inputName | Equals | {!$Record.Opportunity.Account.Name} |
| RPAInputBody > inputArguments > inputAddress | Equals | {!$Record.Opportunity.Account.BillingStreet}, {!$Record.Opportunity.Account.BillingCity}, {!$Record.Opportunity.Account.BillingState} {!$Record.Opportunity.Account.BillingPostalCode} |
| RPAInputBody > inputArguments > inputEmail | Equals | {!$Record.Opportunity.Account.Owner.Email} |
| RPAInputBody > inputArguments > inputPhoneNumber | Equals | {!$Record.Opportunity.Account.Owner.Phone} |
| RPAInputBody > inputArguments > inputComments | Equals | {!Record.Description} |
The above values are what will be passed into the MuleSoft RPA process. Once this is set up, the RPA process can be invoked.
Add Action Element to Invoke RPA Process
Add a new Action Element to the “Run Asynchronously” path. Search for the name of the External Service (e.g. “FillOutWebForm100”). Select the “Start Process V 2”) Action. Give it a Label and API Name (e.g. “RPAStartProcess”). Include a Body, and in the Body section, use the RPAInputBody created in the steps above. Click Done:
This completes the “Run Asynchronously” path.
Next, another path will be added to check the status of the executed RPA process instance and to update the triggering Salesforce object accordingly.
Implement “Two Minutes Later” Path
Add the “Two Minutes Later” Path
Add a new path to the flow which will run 2 minutes after the initial update. Path Label = TwoMinutesLater, Time Source = “When Quote is Updated”, Offset Number = 2, Offset Options = “Minutes After”:
With this path set up, it is now time to add elements.
Add Action to Get RPA Process Execution Status
Add a new Action Element to the “TwoMinutesLater” path. Search for the name of the External Service (e.g. “FillOutWebForm100”). Select the “Get Processes Execution Status V 2”) Action. Give it a Label and API Name (e.g. “RPAGetStatus”). For the Execution Id, select the value used in the previous “Start Process V 2” action step for executionId (e.g. {!Record.QuoteNumber}). Click Done.
This step will check on the given RPA process execution instance and get its data back.
Add Action to Update Triggering Record
Finally, the Quote should get updated with a value from the RPA process which was executed in the “Run Asynchronously” path. The prior step gathered the data via a call to the “Get Processes Execution Status V 2” endpoint. For this example, the Quote’s Customer Notes field will get updated with the outputFormResponse activity parameter value from the RPA process.
Add an element for “Update Triggering Record”.
Add a Label (e.g. “Update Quote with RPA Output”) and API Name.
Set How to find Records to Update and Set Their Values = “Use the quote record that triggered the flow”
Set Condition Requirements to Update Record = “None—Always Update Record”
Set Field Values for the Quote Record. (Note: this example will be specific to the Cloud First Labs use case). This example set agilqt__customerNotes__c equal to {!RPAGetStatus.200.result.oneOfOutputArguments.outputFormResponse}.
Click Save. The Salesforce flow is set up and ready to test.
To test it out, create a Quote. Make sure the fields are set as needed to be input into the RPA process. Then move the Quote into Presented status to trigger the flow. After running, the output can be checked in Postman to verify that the RPA process was triggered:
After the “TwoMinutesLater” path finishes, the Customer Notes should reflect the update provided back by the RPA process:
To see this in action, watch the video created to go along with this post:
Automate Your Salesforce Workflow: Effortless Web Form Filling Using MuleSoft RPA - Part 2 - YouTube
Tap to unmute
Automate Your Salesforce Workflow: Effortless Web Form Filling Using MuleSoft RPA - Part 2 CloudFirst Labs
CloudFirst Labs202 subscribers
Conclusion – Web Form Filling Using MuleSoft RPA
Yes, these two complementary posts were long but worth it! Repeating it is easier once you build one of these processes and successfully test it. Web Form Filling using MuleSoft RPA is just one of the many use cases where this technology really shines, and proves you don’t need an API-enabled application to use RPA.
Talk to the Professionals!
Overview – Web Form Filling Using MuleSoft RPA
There are numerous use cases that show how Organizations can commonly benefit from automating the completion of online Web forms. This post will show how simple it is to fill out Web forms using MuleSoft RPA, and in a subsequent blog article, I will show how to easily set up Salesforce to do this RPA-based form entry. ( Salesforce will even get updated with the RPA process’s output data!) So join me as I walk you through the steps needed for Web Form Filling Using MuleSoft RPA Builder below.
Set up Activity Parameters
Our example shows a process with 7 activity parameters; 6 of these are to be provided as inputs to the process, and 1 of them gets set as an output from the process. (An activity parameter can be used to serve input purposes, output purposes, both, or neither, but in this case, each one is useful specifically just for input or for output.) The values for these activity parameters can be defaulted from RPA Builder:
Set XPath Variables
As shown in the screenshot above, my RPA process has a few XPath-related variables set. These XPath variables (nameXpath, emailXpath, etc.) hold the XPaths to navigate to a given field within a Web page. For some Web pages, these XPaths are easy to find and can even be done using RPA Builder’s handy Browser Wizard. For some Web pages with more complex UI’s (with a vastly complex set of HTML elements used to build out the screen), it may take some experimentation using Chrome Developer Tools to figure out the appropriate XPath to use to navigate to a given field on a Web page. An example Xpath variable value from the example RPA process is:
- nameXpath = //span[text() = ‘Name’]/parent::div/parent::div/parent::div/parent::div//input
These XPath-related variables are set so they can be used in later action steps: one step to clear any data out of said field, another step to write the new value into said field.
Clear Web Elements
Now that the XPath elements are set up, add a “Clear Web Element” action step for every field that might need data cleared out. This can be important in case the field comes pre-populated for one reason or another:
Click Web Element and Enter String
The next steps are to Click Web Element and Enter String. Click Web Element will bring focus to the relevant field (based on the XPath-related variable set earlier). The Enter String gets configured with the appropriate activity parameter value.
After doing this for each relevant field, it is now time to use one more Click Web Element to submit the Web form:
Get Response Text
After clicking Submit, the RPA process gets taken to a new Web page. From this Web page, the RPA process will capture some text from the screen using a Get Web Element Text action step using XPath:
The following step is a Set Variable so that the value from that Web element can be set on an activity parameter (outputFormResponse, in this example’s case):
This sets the response on that activity parameter, allowing it to be referenced by invokers of this RPA process. (As we will see in Part 2 of this series, Salesforce [or another system] can kick off this RPA process and use the data from the outputFormResponse activity parameter).
After configuring this setup for the example Web form (and the input/output fields therein), the RPA process in RPA Builder looks like what is shown in the following screenshot:
Conclusion – Part 1
By following this example, you can see how easy it is to complete Web Form Filling Using MuleSoft RPA and automate Web-based data input and output, especially when you want to set it up to write to or read from Web pages. By setting up such a MuleSoft RPA process as an invokable configuration (as shown in an earlier Cloud First Labs post about MuleSoft RPA), another system can programmatically provide proper input to a Web form and utilize the output provided by the RPA process. Part 2 of this series will specifically show this capability by having a Salesforce flow use this example Web form RPA process.
A walk-through video demonstration of the steps I took can be found here on our YouTube channel:
Automate Your Salesforce Workflow: Effortless Web Form Filling Using MuleSoft RPA - Part 1 - YouTube
Tap to unmute
Automate Your Salesforce Workflow: Effortless Web Form Filling Using MuleSoft RPA - Part 1 CloudFirst Labs
CloudFirst Labs202 subscribers
Talk to the Professionals!
MuleSoft and EDI, the dynamic duo
Much of the business world runs on business-to-business (B2B) Electronic Data Interchange (EDI) transactions. The data in these EDI transactions is difficult for humans to read, but MuleSoft makes it simple to work with. This example will walk through the straightforward process for converting an input EDI file (an X12 810 Invoice) to and from a more human-readable JSON format. Note: While it isn’t shown here, MuleSoft can handle any additional transformation and orchestration of this data. Whether the EDI data needs to be used to update your ERP, update your CRM, notify a user, or perform any other processing, MuleSoft and EDI enable great solutions.
Design Center
For this MuleSoft and EDI example, we created an API specification in Design Center. This API specification is a standard MuleSoft development practice; it is not the focus of this post. However, note that this example API specification has two endpoints: one for taking in an input X12 810 (Invoice) payload and returning invoice JSON as a response payload, and one for taking input invoice JSON and converting it to an X12 810 (Invoice) response payload. The API specification defines the data structure of the JSON invoices. The spec is named example-edi-papi (for “Example EDI Process API”) and published to Exchange so that it can be imported into Anypoint Studio to develop from.
Anypoint Studio Development
In Anypoint Studio, we create a new Mule project and have it import the latest published version of example-edi-papi from Exchange.
This creates a basic MuleSoft project and stubs out Flows for each endpoint in the imported API (so, one for /810-to-invoice-json and one for /invoice-json-to-810).
This example requires the X12 Connector from Anypoint Exchange. To get it, go to the Mule Palette -> Search in Exchange -> Search for “X12”. Select the “X12 EDI Connector – Mule 4” and click Finish:
This opens up 3 X12-related options in the Mule Palette:
Read, Write, and Write Batch. This example will use the Read and Write components. (The Write Batch component is useful for merging multiple transactions into a single X12 payload; this example demonstrates a simpler case.) The /810-to-invoice-json flow will use Read as the flow will read the input X12 810 message and transform it (using DataWeave) to JSON. The /invoice-json-to-810 flow will use Write as it will convert the input JSON to a Map object and the Write component will convert the Map object into text formatted as an X12 810 document.
For this MuleSoft and EDI example, the flows will look as follows:
As shown, the X12 Read component takes the input (the POSTed X12 810 payload) and generates a Map object. A DataWeave Transform is used to convert from the Map object to the specified JSON format. And as shown, the invoice-json-to-810 flow’s DataWeave Transform component takes the input (the POSTed JSON matching API spec format) and generates a Map object. The X12 Write object takes the Map object and generates the X12-810-formatted response.
To get this to work, the X12 components must be configured. In this case, the Read and Write components can both reference the same X12 Connector configuration: X12_810_EDI_Config
To set up the configuration initially, create a new Connector configuration by clicking the green Plus sign from the prior screen shot. This pops up the X12 EDI Config window. Many settings can be toyed with, but the key setting is Schema definitions. Change this to “Edit inline” and enter a value of “x12/004010/810.esl” and click OK. This sets up the X12 configuration to be pointed at version 004010 of the 810 (Invoice) schema.
Note: To see additional schemas you can choose from, go to your project in Package Explorer and find “X12 EDI”. Expand this and expand x12-schemas-
After configuring the X12 EDI Config, set X12_810_EDI_Config as the config for both the X12 Read and the X12 Write component in the application.
With this set up, a very interesting exercise is to simply send a valid X12 810 message to the /810-to-invoice-json endpoint and setting a breakpoint directly after the Read component to examine the Map object generated by the X12 Read.
From this object generated by the Read component, a DataWeave transform can be applied to produce the appropriate JSON. This post won’t go into detail on that DataWeave transformation, but just know that it is a standard MuleSoft DataWeave transform. MuleSoft makes the transformation straightforward and even provides helpful examples in Anypoint Exchange in case developers are struggling to get started with these X12 data transformations for MuleSoft and EDI.
The invoice-json-to-810 flow does the transformation in the opposite direction, so the DataWeave transformation is the first step of that flow.
The details of this DataWeave transformation are not the important piece of this example; the transform details will differ from use case to use case. However, this example shows just how easy it is to work with X12 data in MuleSoft and convert it to and from whatever data types are required to run the business.
Not only can MuleSoft help transform the data to and from many different formats, but it can be set up to handle the connectivity to downstream systems which require some or all the data contained in the X12 transaction sets. From batch to real time, from JSON to X12, and from API to EDI, MuleSoft is a powerful integration platform with capabilities to easily handle numerous MuleSoft and EDI use cases.
Check out the linked video below to see this in action in a live example.
MuleSoft and EDI Easily Transform X12 Data - YouTube
Tap to unmute
MuleSoft and EDI Easily Transform X12 Data CloudFirst Labs
CloudFirst Labs202 subscribers
Talk to the Professionals!
The Follow-Up: Why Even Invoke a MuleSoft RPA Process via HTTP?
As we learned in the first article in this series, many RPAs need to be callable via HTTP. In these such cases, the RPA process must be published to the Production phase with an invokable run configuration. Credentials (via a Connected App) must be created to authenticate to the RPA API URL and the URL must be retrieved from Anypoint Exchange. Those steps were covered in Part 1 of this 2-part series. The RPA API URL and API Key can be used in Postman to start the execution of the RPA process and to get the status and details of the process execution.
- Get the RPA API URL from Exchange and the API Key from RPA Manager, per the steps in Part 1
- Create and send a request in Postman to start the process execution
- Create and send request(s) in Postman to get process execution status and details
Start RPA Process Execution via Postman
Open Postman and create a PUT request to the URL copied out of Exchange in Part 1:
Next, go to the Authorization tab. Select Type = “OAuth 2.0”. In “Header Prefix” type “Bearer”. Leave the Token field blank initially; the following steps will go get a new token:
Scroll down to Configure New Token. In Token Name, enter whatever meaningful name you want to represent this OAuth access token. Select Grant type = “Client Credentials”. For the Access Token URL, type:” https://anypoint.mulesoft.com/accounts/api/v2/oauth2/token”. In Client ID, paste the ID you copied from Anypoint Platform Access Management in Part 1. In Client Secret, paste the Secret that you copied in Part 1. Leave Scope blank, and for Client Authentication, set “Send as Basic Auth header”. Scroll to the bottom of the panel and click the “Get New Access Token” button:
This will use the provided Client ID and Client Secret to go get a new token from the provided Access Token URL. A Postman popup should show that the token was successfully generated and then show a screen for managing access tokens. It shows the access token value. Click Use Token:
Once the popup goes away, the token value is now being used in the request for authorization.
With a valid token in place, it is time to set up the actual request.
Go to the Body tab. Set it as a “raw” body and set the type = “JSON”.
In the body, specify an “executionId” and the values of any “inputArguments” that you want to set. The executionId is a unique ID that is used to find the status and output data of this specific RPA process execution (one executionId can only be used once). These inputArguments are the input values for the RPA process’s activity parameters; any values not set here are set to the default values configured in the Invokable Run Configuration set up in Part 1 of this series. After setting the payload, hit Send to fire off the request. If everything is configured correctly, a 201 Created status is returned. (Note: If you re-run the PUT command for the same executionId, these follow-up requests will receive 204 No Content statuses as responses, meaning that a new execution was not created.)
Get RPA Process Execution Details via Postman
After sending the PUT request to kick off the RPA process, a GET request can be sent to get the status and details of that process’s execution. As shown in the Exchange page for this RPA process’s REST API asset, there is a GET endpoint for getting these details. The URL is the same endpoint as the prior PUT request URL, except it has “/
After sending a PUT request for executionId = “CloudFirstLabs_Test1”, send a GET request to …/executions/CloudFirstLabs_Test_1. The request should use the same access token as the prior PUT request (Authorization type = “OAuth 2.0”, select the token from the dropdown or paste the token value from the other request). The payload for this request is empty, as it is a pure GET command.
If this GET request is sent immediately after creating the process execution, the response’s message will probably say “The process execution is in status notStarted”.
If it is sent while the RPA process is executing, the response message will say “The process execution is in status running”.
If the GET request is sent after the RPA process executes successfully, the response message will contain a status of “success” and the result object will hold the values of the RPA process’s activity parameters.
Conclusion
By using the steps from Part 1 and Part 2 of this series, we have shown how to enable a MuleSoft RPA process invocation via HTTP and Postman. This process can be applied to many scenarios and use cases. Watch the second part of the video here:
Invoke MuleSoft RPA Process via HTTP and Postman Part 2 - YouTube
Tap to unmute
Invoke MuleSoft RPA Process via HTTP and Postman Part 2 CloudFirst Labs
CloudFirst Labs202 subscribers
Talk to the Professionals!
To learn more about our MuleSoft RPA or Salesforce services, please visit our website or fill out a Contact Us form here.
Why Even Invoke an RPA process in MuleSoft using HTTP?
Simple! Sometimes, it is required that a system Invoke an RPA process in MuleSoft using HTTP so that another system can call said RPA process. In such cases, the RPA must be moved into the Production phase and an Invokable Run Configuration must be configured for it in MuleSoft RPA Manager. After creating the invokable run configuration, the URL for invoking the RPA can be found in Anypoint Exchange. To keep everything secure, credentials will also need to be set up for authorizing the HTTP request to the API.
Given an RPA process that has successfully completed its test plans in the Test phase, follow the steps below to create an Invokable Run Configuration.
- Create a Connected App that can invoke RPA APIs.
- Promote the RPA process to the Production phase in RPA Manager.
- Set up an Invokable Run Configuration.
- Get the RPA’s URL from Anypoint Exchange.
Details on each of the steps above will be explained below.
Create a Connected App
Log in to Anypoint Platform and navigate to Access Management. (This step requires the logged-in user to have Organization Administrator permission in Access Management.) From there, click Connected Apps in the left-hand panel. Then click the “Create app” button:
Enter a Name for the Connected App, and for Type, select “App acts on its own behalf (client credentials)” and click “Add Scopes”:
In the Add Scopes pop-up, find and select “RPA Invocable Process” and then click Next:
Select the Business Group(s) that the relevant RPA processes belong to and click Next. Then finally click “Add Scopes”:
Then click Save, at which point the Connected App is created. It should now show on the Connected Apps page, where you can click “Copy Id” and “Copy Secret”. Be sure to save the Id and Secret values; these will be used later for invoking the RPA via HTTP call.
Promote the RPA Process to the Production Phase
Promote the RPA process to the Production phase in RPA Manager. To do this, go to RPA Manager -> Process Automation -> Process Management. Select the relevant Category. Then select the relevant RPA process. Click the “Publish (Production)” button. In the pop-up window, check the checkbox to confirm the release of the process and click “Release to Production”:
Create an Invokable Run Configuration
To set up an Invokable Run Configuration on an RPA process that is in the Production phase, navigate to that RPA process in RPA Manager. To do this, go to RPA Manager -> Process Automation -> Process Management, then select the relevant Category and Process. Then under “Production configurations”, select “Create an invokable run configuration”.
Enter a name and description:
Configure the default values for the process’s activity parameters:
Configure any needed user tasks:
Configure the Execution (“Run in secure session as default user” is recommended):
Configure the bot(s) for the process to run on:
And lastly, click “Save & Publish”.
Get the RPA API URL from Anypoint Exchange
Upon creating the invokable run configuration for the RPA process, a “REST API” asset gets created in Anypoint Exchange. Within that asset, the URL can be found for invoking the RPA process via HTTP. To find the URL, navigate to Exchange. Then search for the name of the RPA (in my case, my RPA process is named “Get Widget Data from Legacy Inventory Site”) and select the asset with a matching name and a type = “REST API”:
After clicking the link to open the REST API asset, the asset’s Exchange page opens. Click on the second entry under Endpoints (the one starting with “/v2/”; this v2 URL is the one required for use with OAuth 2.0-based Connected App credentials we are using in this demo) in the left-hand panel to expand it.
Then click on the PUT startProcessV2 link:
After you do this, it will show a URL on the page:
This is the URL that will be used in Part 2 of this series to show how to use Postman to invoke the RPA process. Stay tuned for Part 2 next week! Until then, watch the video version of this blog on YouTube:
Invoke MuleSoft RPA Process via HTTP and Postman Part 1 - YouTube
Tap to unmute
Invoke MuleSoft RPA Process via HTTP and Postman Part 1 CloudFirst Labs
CloudFirst Labs202 subscribers
Talk to the Professionals!
Overview
We know that RPA processes are excellent for automating screen work. However, with MuleSoft RPA, they can be used to consume OAuth-Secured APIs and use data from the response! In this blog, I will show how to build a MuleSoft RPA process that successfully gets and uses data from an API that is secured in Anypoint Platform by OAuth 2.0. [Note: This approach works whether the OAuth-secured API is built in MuleSoft or another technology.]
The key steps here are:
- Know the URL and credential details needed to get a valid OAuth token. (Assumed to be set up as a prerequisite)
- Know the URL and payload details needed to get a valid response from the actual API. (Assumed to be set up as a prerequisite)
- In MuleSoft RPA Builder, add activity parameters for the values mentioned in (1) and (2)
- In RPA Builder, add a REST Call for the OAuth token request.
- In RPA Builder, add a JSON Query action step to parse the access_token from the response.
- In RPA Builder, add a REST Call for the actual API request (and reference the parsed access_token).
- In RPA Builder, use JSON Query action steps to parse the relevant data from the API response.
Primer on OAuth 2.0 and OAuth-Secured API
APIs secured by OAuth 2.0 require a valid access token to be sent as authentication and authorization, usually as an HTTP header. The OAuth 2.0 provider has a URL endpoint that provides a token when a requestor sends a valid request to the URL (with appropriate Client ID, Client Secret, grant_type, and scope details). The token is usually valid to be reused for some arbitrary amount of time, such as one hour. But if no token is already cached, the token can be used as part of a two-step process for calling an API:
- Call OAuth Token endpoint with valid information to get back a valid access token.
- Put the token returned in (1) into an HTTP header and send a request with that header and appropriate payload to the actual API.
This two-step process is what will be used in this walkthrough.
Add REST Call Step for 2 REST Calls in RPA Builder
[Note: the following steps assume the OAuth and API details for your use case are set up and known in advance.]
In RPA Builder, create activity parameters for the following fields.
- apiURL (alphanumeric Variable for the actual API URL to call)
- oauthTokenURL (alphanumeric Variable for the OAuth Token URL to call to get access token)
- oauthClientCredentials (User Account Variable for the Client ID and Secret for getting token)
Map those activity parameters to your workflow.
Add a REST Call Step for Getting OAuth Token
Then, add a REST Call from the Toolbox for the OAuth Token call. Set it up as a POST request with no payload body. Map the oauthTokenURL as the Base Url.
Then go to the Header Parameter tab and the following headers:
Content-Type = application/x-www-form-urlencoded
Accept = */*
Then go to the Query Parameter tab and map the following parameters:
grant_type = client_credentials
scope = myscope1 myscope2 (Your use case may differ; these are example scopes I set up for my example API)
Finally, go to the Authentication tab. Select Authentication Type = Basic Auth and map your oauthClientCredentials activity parameter to the User Account field. Click OK.
Add JSON Query Step to Parse access_token
Following this step, add a JSON Query action step from the Toolbox.
Configure the Json Object as the REST Call’s Response Body, and use a JSONPath Expression of $.access_token to parse out the token value.
Add REST Call Step to Call Actual API
Now that the access_token has been generated and parsed, create a REST Call step to call the actual API.
Map the apiURL activity parameter to the Base Url field. The rest of the details on the Settings and Request Body tab are dependent on the specific API being called.
On the Authentication tab, set the Authentication Type as Bearer Token and map the Json Query FirstItem to the BearerToken field.
Click OK.
Use JSON Query Step(s) to Parse Relevant Values from API Response
Like the section above used a JSON Query step to parse the access_token value, JSON Query steps are also used to parse relevant values from the actual API response (assuming the API uses JSON). See the screenshots below to see how values were parsed from an example API.
Now you are able to capture the response! While many steps, we have shown the power of using the above approach way to utilize API-based data inside a MuleSoft RPA process. This is only one example of the limitless use cases that exist for this technology, and clearly shows how a customer can maximize their automation environment to do more than just screen work. Check out the accompanying YouTube video on our channel:
Call an OAuth-secured API from MuleSoft - YouTube
Tap to unmute
Call an OAuth-secured API from MuleSoft CloudFirst Labs
CloudFirst Labs202 subscribers
Talk to the Professionals!
About Robotic Process Automation
Many organizations are searching for ways to reduce operational costs while increasing the accuracy, quality, and consistency of manually executed tasks. Robotic Process Automation (RPA) is a way to achieve these goals. RPA technology allows configurations of “bots” that mimic human-computer interactions to perform tasks at high volume and speed. Tedious, repetitive tasks and business-rule-driven processes are good candidates to be executed by RPA bots. These bots can extract data from applications and copy data between systems, even legacy applications and other systems that lack APIs.
MuleSoft RPA is a powerhouse RPA technology platform that enables organizations to take advantage of the benefits of automation. MuleSoft is a longtime leader in integration technology and has built MuleSoft RPA to extend solutions even to systems with insufficient traditional integration solutions (such as Web Services or APIs). On top of its integration expertise, MuleSoft comes with the added benefit of being a Salesforce company. The Salesforce backing means MuleSoft RPA customers can count on quality support from the Salesforce organization and experienced Salesforce-partnered strategic implementors.
With its toolset of RPA Recorder, RPA Builder, RPA Manager, and RPA Bots, MuleSoft RPA makes automation development straightforward to build, to maintain, and to execute. Whether a given RPA process needs to run once, run regularly on a schedule, or run dynamically via HTTP request, MuleSoft RPA can set up the processes as required. MuleSoft RPA enables organizations to connect difficult-to-integrate systems, to reduce monotonous work, and to improve quality of business operations.
Automating Repetitive Tasks
RPAs are effective across a variety of industries. They are especially useful for automating “swivel chair tasks”. Swivel chair tasks are processes that are carried out by employees manually entering the same data into multiple systems, often toggling between tabs, applications, or terminals to do so. This type of work tends to feel a little “brainless”. This is often uninspiring to the employee(s) and it can lead to employee dissatisfaction. Many of these boring repetitive processes are error-prone due to the manual and repetitive nature of work.
RPAs can even the speed of execution for these processes. RPA bots can often be configured to carry out their specific work much more quickly than a human visually and manually working through a process. And since the RPAs can be triggered automatically, the processes do not need to wait for the availability of the employee. Pushing the work to the RPA bot allows the workflow to quickly reach its next relevant step while the employee is freed up to perform more engaging and higher-value work.
Many legacy systems utilized by organizations require significant amounts of swivel chair work. Legacy systems often lack API capabilities or have APIs insufficient for the business needs of a given organization. Often, the organization is dependent on such legacy systems anyway and employees do tedious data scraping and copy/paste tasks to and from these systems. This work is vital to an organization’s business needs but is burdensome based on the manual efforts required. RPAs can be used integrate these key legacy systems with more modern systems in an automated and robust fashion, paving the way for innovation and more efficient processing. Serving as a bridge from legacy to more modern applications, RPAs can play an important role in an organization’s digital transformation strategy.
Cloud First Labs’ Recommended Solution: MuleSoft RPA
At Cloud First Labs, we recommend using MuleSoft RPA to take care of organizational automation needs. It is backed by technology industry leaders, it supports the entire automation lifecycle, and its set of tools plugs in seamlessly to integrated, modernized environments. MuleSoft RPA provides outstanding solutions for eliminating waste and gaining technological efficiencies throughout an organization’s business processes.
MuleSoft RPA: Backed by Industry Leaders
MuleSoft RPA is built by MuleSoft, which has been a leader in the integration software industry since its founding in 2006. MuleSoft has developed a top-tier integration platform as a service (iPaaS): Anypoint Platform. The Gartner Magic Quadrant for Integration Platform recognizes MuleSoft as a leader in the integration world, and MuleSoft’s RPA Manager and associated tools fit right into the award-winning Anypoint Platform. With MuleSoft long recognized as a leader in integration technology, MuleSoft RPA provides yet another tool for ensuring businesses can connect with and integrate all sorts of disparate systems to accomplish business processes as effectively as possible.
The MuleSoft support process is a crucial part of MuleSoft’s success, and that support is available to MuleSoft RPA users the same way it is available to users of MuleSoft’s other myriad of products and services. The same way MuleSoft’s products help systems connect with other systems across the world, their support team likewise connects worldwide customers with the support they need. With a large and helpful team of support staff scattered across several continents, MuleSoft has the organizational infrastructure in place to provide effective support promptly regardless of what the issue is, when it happened, or where the event took place.
Part of the reason for MuleSoft’s trustworthiness and success is the fact that it is a Salesforce company. Salesforce acquired MuleSoft in 2018 and it has helped grow and deepen MuleSoft’s documentation, support, and capabilities. Salesforce was selected as the Best Software Company in 2024 by G2. With MuleSoft’s deep roots in integration and Salesforce’s backing and support, customers can be confident that their experience with MuleSoft RPA will be best-in-class.
MuleSoft RPA: Supports Whole Automation Lifecycle
There are several phases to the process automation lifecycle, MuleSoft RPA provides a full framework of tools that enable organizations to perform every aspect of it. From Evaluation to Design to Build to Test to Production (Deploy and Monitor), MuleSoft RPA ably provides useful and fully-featured tools.
Tasks and business processes should initially be vetted to see whether they are a good fit for automation. MuleSoft’s RPA Manager can be used to help identify whether a given process is a good candidate for automation. Out-of-the-box functionality includes industry-standard settings for evaluation, but it allows for customization specific to organizational needs. Furthermore, the RPA Manager provides tooling to help determine the break-even point for when a given automation becomes profitable.
The design phase is important for budding RPA processes; this is where the overall approach and flow are identified and visually illustrated. RPA Manager is used in this phase to build out a design diagram using industry-standard Business Process Model and Notation (BPMN). The BPMN diagram built in RPA Manager can be used in RPA Recorder which is useful for “recording” a user’s actions on a computer as they work through a given business process. In RPA Recorder, the actions taken by the user can be fit into the relevant components of the BPMN diagram and documentation can be captured at each step along the way for later use in the Build phase.
MuleSoft RPA’s tool for the Build phase is the aptly named RPA Builder. In RPA Builder, the development of the actual RPA work is completed. Using the aforementioned BPMN diagram and/or the documentation and workflow steps generated by RPA Recorder, RPA Builder takes the output of the design process and turns it into the actual steps to be completed by an RPA Bot. RPA Builder is where the exact steps to be executed by eventual RPA bots are configured; this is where the instructions for the bot to “click here” or to “enter XXX text here” are set up. RPA Builder has a vast toolbox of options that allow for nearly any type of on-screen activity to be configured: from clicking to parsing Web pages to scraping text via Optical Character Recognition (OCR), and beyond. RPA Builder enables the builder to not only build bot instructions but also debug and test them. In RPA Builder, input data and output data (both represented as Activity Parameters) can be configured to ensure the RPA process receives and returns appropriate data.
MuleSoft RPA Builder tool
After publishing an RPA process built in RPA Manager, the RPA process moves from the Build phase to the Test phase. The Test phase is vital to the lifecycle of an RPA process, and it requires two main components of MuleSoft RPA: RPA Manager and one or more RPA Bots. An RPA Bot is a Windows computer or VM configured to be able to run MuleSoft RPA processes. RPA Manager is used to configure test plans and to determine which RPA Bot(s) to execute a given test plan on.
Once the RPA process has been suitably tested, it is ready to move to the Production phase. Similar to what gets configured in the Test phase, this configuration uses a combination of RPA Manager and RPA Bots. RPA Manager sets up the schedule or invokable nature of the relevant RPA process and it provides configurations for default Activity Parameter values and for the RPA Bot(s) the process will get deployed to. Upon execution of the deployed processes, the executing RPA Bots provide ample data back to the RPA Manager for monitoring (including near-real-time screen look-ins), for checking success/failure status, and for troubleshooting.
Deploy a bot using the MuleSoft RPA manager
Evaluation, build, design, testing, and production are all important phases of building RPAs. No matter what part of the RPA process is involved, MuleSoft RPA has tooling to support organization automation success.
MuleSoft RPA: Seamlessly Plugs into Integrated Environment
MuleSoft RPA does not operate in a silo; it can seamlessly tie into various technology environments and platforms. While there is special tooling that makes MuleSoft RPA even easier for existing MuleSoft or Salesforce customers, MuleSoft RPA can be readily utilized in a wide variety of environments.
Production-phase MuleSoft RPA processes can be invoked via HTTP API calls if configured in such a way, that if an outside system needs to trigger an RPA process, it just calls the generated RPA API URL generated by RPA Manager (found in Anypoint Exchange). Anypoint Platform’s API Manager can be used to secure this RPA API URL. In cases where other systems cannot invoke an RPA process, RPA Manager enables the process to be scheduled to run on a specific frequency. This is useful in cases where a given process should be run consistently (whether hourly, daily, weekly, etc.).
Not only can RPA processes be triggered by an API call, but RPA processes can call other APIs as well. As part of the Toolbox in RPA Builder, RPA processes can make outbound API calls and use the returned data.
The ability of RPA processes to be called as APIs and to call other APIs helps bring otherwise disparate manual processes into an overall flow. These abilities provide a way to combine automated data transfers with “manual” clicks seamlessly into an integrated process to operate a business efficiently and effectively.
Closing
Organizations are dealing with inefficiencies and problems related to the manual completion of repetitive tasks, to double data entry, and to legacy system integration. MuleSoft RPA is backed by industry leaders MuleSoft and Salesforce (and supported by an ecosystem of Salesforce partners like us at Cloud First Labs) and provides solutions. From RPA process evaluation through process monitoring, MuleSoft RPA provides a wide array of tools that enable organizations to implement high-quality automations.
Talk to the Professionals!
To learn more about our MuleSoft RPA or Salesforce services, please check out our website or fill out a Contact Us form here.
Why Use MuleSoft RPA?
For the first blog post in our series “Solving Data Collection and Processing Challenges using Salesforce and MuleSoft RPA”, we’re addressing a common scenario, getting data from a web page or HTML. Whether or not you are on the Salesforce platform, you will want to use MuleSoft RPA. The speed, ease of use, feature set, and interoperability with other platforms make it the Go-To choice for us.
In many Use Cases we see with customers, there is a requirement to build Robotic Process Automations (RPA) that iterate over data of unknown length inside a Web browser or from a web page. Consider the scenario where a customer needs an automated process to find all Widget Names on an inventory Web page where Build Category = “Boom Box”.
Widget data table
The process does not know how many records are going to be on the page during any specific RPA execution instance, nor does it care. As long as it finds the Build Category that it is looking for, everything will work.
How to get it done.
To iterate over this data in MuleSoft RPA Builder, simply use a For Loop with a Managed Block inside of it which breaks out of the loop once an iteration is reached with no data found. To do this:
Open a Web Session. Inside of this Web Session, add a Loop element with a very high number of iterations (more iterations than will be realistically encountered). Inside the Loop element:
- Place a Managed block
- Inside the DoAction section of the Managed block:
Add a “Combine Strings” element to generate an XPath to the relevant data using the loop iteration number)
Add a Get Web Element Text element which uses the prior-generated XPath to find the relevant data
Inside the OnError section of the Managed block:
Add a “Force OK State” element
Add a “Break Loop” element
Note: This “OnError” section of a Managed block is the equivalent of the “catch” section of a Try/Catch block in regular programming
Note: This OnError section will get called the first time there is nothing found for the XPath defined in the DoAction section. So if there are 4 records, and the XPath looks for the 5th record, it will fail and the execution will flow into this OnError section.
Build your MuleSoft Workflow like this
In the above example, the Combine Strings element is configured as follows. Pattern = (//tr[td[text() = ‘Boom Box’]]/td[1])[{1}] (where {1} is the loop iteration)
Combine Strings Wizard
Next, the Get Web Element Text element is configured as shown below, referencing “XPath to Widget Name.Combined String”:
Use the Get Web Element Text Wizard
Using this pattern and this Kickstarter, you can adapt the above approach as necessary for your use case.
Conclusion
While this is a very simple example, we have illustrated the power and potential of MuleSoft RPA. With this article as a guide, it is simple to iterate over Web data tables of unknown length using MuleSoft RPA. You can watch the video on YouTube here:
Iterate Over HTML Data in MuleSoft RPA - YouTube
Tap to unmute
Iterate Over HTML Data in MuleSoft RPA CloudFirst Labs
CloudFirst Labs202 subscribers
Talk to the Professionals!
To learn more about our MuleSoft or Salesforce services, please check out our website or fill out a Contact Us form here.
reCAPTCHA
Recaptcha requires verification.
protected by reCAPTCHA