Working with Workday® R-a-a-S Reports Using MuleSoft®
MuleSoft® is a leading platform for building application networks and Workday® is a leader in Cloud-based ERP solutions (finance and human resources). Workday and MuleSoft® are technology partners and part of MuleSoft’s grand vision of achieving a network of applications.
MuleSoft® has a mature Workday connector which gives the capability to call very powerful set of Workday Webservices that give us access to read and write data into Workday®. However, if we need information that spans across Workday business objects or if we need some complex querying the standard web services might not be the answer.
Here is where Report-as-a-Service comes to the rescue.
What is R-a-a-S (as it applies to Workday®)
As the name suggests, we can expose Workday® reports as a REST or SOAP web service. It is ridiculously simple to web-service-enable your custom report. You just have to click a checkbox and your web service is ready.
Points to remember:
1.Per Workday® recommendation, we should never use the standard reports for R-a-a-s integrations.
2.While creating the custom report in Workday, always select ‘report type’ as ‘advanced’. Simple report types cannot be exposed as a web service.
How to create a R-a-a-S report
Check the box to ‘Enable As Web Service’ and you are on your way.
Once the report creation is complete, you can get a link to the Web Service as shown below.
You can get a link for WSDL, CSV, RSS or JSON formats.
We can use this link and call the relevant REST or SOAP service as required.
We can test our API using Postman:
Call the REST API using Mule
Error Handling in Mule
— Mansi Shanbhag
The new Error Handling is one of the major changes introduced in Mule 4. It’s better and more efficient. Although may seem complex to some, it’s made complex for good.
To begin with, the message exceptions can now be handled at 3 different levels i.e. application, flow and processor levels, as shown below.
|Application Level||Flow Level||Processor Level|
The handlers written at the application level are global handlers which can be used to handle the errors thrown by any flow, which doesn’t have its own error handling.
If there is no error handling written at any of the levels, the Mule Default Error Handler is used, which stops the execution of the flow and logs the exception.
The Mule Default Error Handler is not configurable but, can be replaced by our own Global error handler by creating a Configuration global element.
About Error Objects
Every error that is thrown, creates an Error object named as follows – Namespace (eg. HTTP) and Identifier (eg. BAD_REQUEST)
Eg. HTTP: BAD_REQUEST, WSC: CONNECTIVITY, VALIDATION: INVALID_BOOLEAN
Each error object has 2 properties:
- errorType – an object holding the Namespace and identifier
- description – a string holding the error message
All the errors follow a Hierarchy as shown below. “ANY” is the most Generic parent.
About Error Handler Scopes
There are two error handler scopes in Mule 4, i.e., On Error Continue and On Error Propagate which can be used to handle different kind of errors at all three levels.
The ON ERROR CONTINUE scope always returns a success response to the next level, while the ON ERROR PROPAGATE always propagates the error to the next level and returns an error response to the next level.
Each scope can have one or more message processors.
About Global Handlers
To handle errors at application level, add an error handler in the global.xml (or simply outside a flow).
Then, create a Configuration element in the global elements which sets the Global Error Handler as the Default Error Handler.
To create a generic handler for handling all the errors, specify the TYPE as “ANY” in the error scope of the Global Handler. To handler multiple errors, different type or errors separately, specify the errorType of the error in the Type box of the error scope.
The error will be handled by the first scope which meets the errorType.
About Flow Level Handlers
Flow level handlers can be added to regular Flows and private flows, but not to Subflows.
If an error that is thrown in the flow, doesn’t find a matching scope for its errorType in the Flow’s error scopes, it DOES NOT go to the application level handler, instead it uses the Mule Default Error Handler.
About Processor Level Handlers
To handle the errors at processor level, add one or more processors into a Try Scope and handle it using the On Error Propagate or On Error Continue Scopes.
The error scopes at processor level take precedence over flow level scopes. Flow level scopes take precedence over application level scopes.
It would be a good idea to have an error scope with Type specified as ANY in each level to avoid getting unexpected errors propagated to next levels.
Finally, the most important and challenging part of the new error handling is to choose between On Error Propagate and On Error Continue Scopes. Select them according to the business requirement or logic. For eg.: If you want the child flow to return a success to parent flow so that the parent flow continues, use On Error Continue. Similarly, use On Error Propagate when you may want the error to be propagated from child flow to parent flow and return an error response.
Salesforce Account Issue
— Umesh Naik
Trainers generally face trouble while using the salesforce connector. They get the following error:
The reason for this error is that the free trial is not a developer account.
To use API, your account needs to be any one of these editions and in all these editions, this feature is enabled by default;
- Enterprise Edition
- Unlimited Edition
- Developer Edition
The API package is not available for the following editions:
- Personal Edition
- Group Edition
- Professional Edition
The solution, is to create a developer account with salesforce by using the link below:
The test connection of the salesforce connector was successful when tried with the new developer account.