How to generate Global Error Handler Plugin in Mule 4 - mulesoft

Mulesoft redesigned the whole error handling mechanism and components in Mule 4 (some key difference here). In Mule 3, there was a simple way to reuse a flow across multiple applications by putting into a separate mule-application and package that as jar. Jar can be added as a dependency in any mule-application. An important application of this was having a reusable error response builder flow that possibly analyzes the exception and generates client friendly error response with the proper error code and error message for the REST API client.
But when I am trying this in Mule 4 I couldn't do this. Is there any other way to generate Global error handler plugin in Mule 4?

You can still share Mule 4 configuration XML files in a .jar, you just need to build the file by following some instructions for it to work well in Mule 4. The instructions are explained at this kb: https://help.mulesoft.com/s/article/How-to-add-a-call-to-an-external-flow-in-Mule-4

Related

The LightningMessageChannel named boatMessageChannel was not found in the workspace

In LWC Super badge Challenge 2, we have to create a lightning message channel named BoatMessageChannel.
I tried creating it with the name boatMessageChannel coz the naming should be in the camel case.
But while verifying the channel I'm not able to complete the challenge though I have verified that the channel is properly deployed by including it into lwc.
After searching a while I found that I have to use BoatMessageChannel.messageChannel-meta.xml rather than boatMessageChannel.messageChannel-meta.xml. but while deploying this file I'm getting the following error:
The Lightning Message Channel should be in the camel case is the best practice.
But in challenge 2, they are applying the test case which checks the LMC with Pascal case, and hence it fails to complete.
Note: while deploying from the file editor context we are getting the mentioned error that
SourceElementDoesNotExist: The LightningMessageChannel named boatMessageChannel was not found in the workspace.
To deploy it, we have to right-click on the file from the file explorer which will not give the error mentioned above.

Azure AD B2C Custom Policy Localized REST API Conflict Response

This is sort of an extension of this question here. I have a policy that calls a REST API. The API returns an error message and this message needs to be localized.
One way is to of course get the API to return a localized message, but is there a way for the CustomPolicy itself to localize the error code? According to the CustomPolicy Docs, a REST API can send an error code along with the Conflict error code. Our thinking was to use this error code as a key and select a localized message (from the messageValue enum mentioned in the answer in the link).
However, we can't seem to capture/handle the error data returned by the API. The Policy seems to handle error codes by itself and we would like to know if it is possible to inject localized exception/error messages from the policy itself.
Thanks in advance!
Edit: A little more information about the setup. We have a TechnicalProfile that has a DisplayWidget and a ValidationTechnicalProfile. The DisplayWidget is used for entering & verifying the user's phone/email and the ValidationTechnicalProfile makes the final call to the RestAPI with all the user's information to register him/her. This RestAPI call output is what we want to localize.
The suggestion in the linked SO question, from what I understand, is that we integrate another DisplayClaim (that references an enum) in the DisplayWidget, and depending on the ErrorCode returned by the call, change it to display the appropriate code. However, as per my understanding, this would also require editing the API to return only 200 along with a code. This code would indicate the true nature of the result - success or a code for one of the enums to be displayed.
Our aim therefore is to check if there is a way to follow the Policy's flow (disrupt the SignUp/SignIn process) but at the same time localize the API's displayed response.
We managed to find a workaround to this, so I'm posting this here for anyone else who might be interested in this.
Our restriction for localizations was the fact that used Phrase to manage our translations and wanted the CustomPolicy specific translations all in one place. Our CD workflow was as follows:
PolicyCommit -> Build Variable Replacement through PS -> Release Variable Replacement and localized strings replacement through PS & Policy Uploads
Barring the policy from localizing the APIs response, we had the following options to achieve this:
Sending the language to the API and having the API return the appropriate error message
in the appropriate language. We were reluctant to follow this because of a multitude of reasons, but mostly because we would also have to handle different regions, etc. in the API - something the policy does by itself.
We actually had only one API that we called, and also only two error messages that were used. Hence we created an enum with the two error messages that would be localized. We then used a chain of InputClaimsTransformations that did the following:
Repeat Steps 1 through 3 for all the errors
1. CreateStringClaim (Create ClaimTypes for each of the error codes, holding the index of the error code in the enum)
2. GetMappedValueFromLocalizedCollection (Make the localized enum choose and hold the value of the required error code)
3. AddItemToStringCollection (Add the localized error from the enum to a StringCollection)
4. GenerateJson (Add the error codes StringCollection to the JSON payload to be sent to the API)
This way, the policy performed the localization for all the errors and we sent them along with the request to the API. The API, when an error occurred, picked one of the error messages from the policy and sent it back. This method was for us, because of our CD structure and Phrase integration, much easier than actually having the translations in a file hosted on the cloud to be accessed by the API.
Hope this helps someone; I can also add code in case someone needs it :)

Azure logic app - Transform to XML - MapNotReady

I'm trying to translate an X12 edi message using a map created in VS2015, but I get the following error;
MapNotReady. The map '' is still being processed. Please try again later.
Running the input in VS2015 I get the correct result, but not using Azure Logic Apps
Resolved this issue by creating a new Integration account in a new Resource Group and different Location.
Looks like a bug in Azure, will log call with MS
I faced the same issue after deploying a logic app using ARM template.
What was I doing?
In deploy powershell, I was creating integration account and adding schemas and maps.
Deploying logic app using ARM template.
Immediately after deployment, I tried to execute the logic app. At that point, I received MapNotReady exception in transform action.
However after 10 minutes when I retried the message again, the problem was gone. It looks like, map service was not fully deployed.
So no need to deploy to different resource group. Probably wait for few minutes before executing LogicApps.

Relay JS only on client side

I have developed a graphql server with laravel (https://github.com/Folkloreatelier/laravel-graphql). Now I would like to create a React application by using Relay. When I create my first component, then I receive the error:
Uncaught Error: Invariant Violation: RelayQL: Unexpected invocation at runtime. Either the Babel transform was not set up, or it failed to identify this call site. Make sure it is being used verbatim as Relay.QL.
I still googled the error and I recognized that I need to install the Babel Relay Plugin. But to include this plugin I have to specify a schema. But I still have specified this schema on server side, why do I need this also in client side? Is there any example how to implement this when a server is still implemented (external server, e.g. no NodeJS server).
Thank you for your advice.
The schema for your data on the server-side is required by babel-relay-plugin to do transpilation of Relay.QL fragments in Javscripts that will be delivered to the client-side. However, note that on your GraphQL server, you define the schema in Laravel GraphQL PHP classes, which you need to convert it into JSON format that babel-relay-plugin expects.
For example, I did a similar setup with Rails and graphql-ruby (https://github.com/nethsix/relay-on-rails).
Define the data schema on my server-side using graphql-ruby classes in app/graph directory
Convert the schema into a JSON file using a script lib/tasks/graphql.rake, which I then stash into app/assets/javascripts/relay/data/schema.json
Point to the schema.json in your babelRelayPlug.js file wherever it is (mine is in assets/javascripts/relay/utils/babelRelayPlugin.js)
For Rails, we can easily dump the graphql-ruby schema to json by just calling #to_json method. You may have similar methods in PHP.
I compared the difference between setting up Relay on a nodejs server, vs. a non-nodejs server using an illustration here if it helps (https://medium.com/#khor/relay-facebook-on-rails-8b4af2057152)

Apache Camel: Keeping routing information completely independent of the Java Code

First of all thanks to folks who are currently involved in the development of Camel, I am grateful for all the hard work they have put in.
I am looking for some design advice.
The architecture is something like this:
I have a bunch of Java classes which when instantiated are required to connect to each other and send messages using Apache Camel. The design constraints require me to create a framework such that all routing information, producers, consumers, endpoints etc should be a part of the camel-context.xml.
An individual should have the capability to modify such a file and completely change the existing route without having the Java code available to him.(The Java code would not be provided, only the compiled Jar would be)
For example in One setup,
Bean A ->Bean B->Bean C->file->email.
in another
Bean B->Bean A->Bean C->ftp->file->email
We have tried various approached, but if the originating bean is not implemented as a Java DSL, the messages rate is very high because camel constantly invokes Bean A in the first example and Bean B in the second(they being the source).
Bean A and Bean B originate messages and are event driven. In case the required event occurs, the beans send out a notification message.
My transformations are very simple and I do not require the power of Java DSL at all.
To summarize, I have the following questions:
1) Considering the above constraints, I do I ensure all routing information, including destination addresses, everything is a part of the camel context file?
2) Are there example I can look at for keeping the routing information completely independent of the java code?
3) How do I ensure Camel does not constantly invoke the originating bean?
4) Does Camel constantly invoke just the originating bean or any bean it sends & messages to irrespective of the position of the bean in the entire messaging queue?
I have run out of options trying various ways to set this up. Any help would be appreciated.
Read about hiding the middleware on the Camel wiki pages. This allows you to let clients use an interface to send/receive messages but totally unaware of Camel (no Camel API used at all).
Even better consider buying the Camel in Action book and read chapter 14 which talks about this.
http://www.manning.com/ibsen/
Save 41% on Manning books: Camel in Action or ActiveMQ in Action. Use code s2941. Expires 6th oct. http://www.manning.com/ibsen/
If you consider using ServiceMix of FuseESB, you might want to separate your routes in two parts.
First part would be the Event-driver bean that trigger the route. It could push messages to the ServiceNMR (see http://camel.apache.org/nmr.html).
The other part would be left to the framework users, using Spring DSL. It would just listen to message on the NMR (push by the other route) and do whatever they want with it.
Of course endpoint definition could be propertized using servicemix configuration service (see http://camel.apache.org/properties.html#Properties-UsingBlueprintpropertyplaceholderwithCamelroutes)

Resources