Error Handling by Scatter-Gather Routerįirst, we must have knowledge on the kind of error that can be generated within Scatter-Gather component. It executes every route in parallel and not sequentially. Schematic Diagram of Scatter-Gather Routerįollowing is the schematic diagram of a Scatter-Gather Router having four event processors. Here the condition is that the S-G router will pass a consolidated Mule event to the next event processor only when every route is completed successfully. After this, it passes this consolidated Mule event to the next event processor. Next, this router gathers the created Mule events from each route and then consolidates them together into a new Mule event. Every Mule event will have its own payload, attributes as well as variables. Each route in this case will create a Mule event by using a separate thread. The condition is that each route must be a sequence of one or more event processors which is like a sub-flow. We can understand its working with the help of following two points −įirst, this router copies (Scatter) a Mule event to two or more parallel routes. As its name implies, it works on the fundamentals of scatters (copy) and Gather (Consolidates). Scatter-Gather RouterĪnother most used routing event processor is Scatter-Gather component. Following is the schematic diagram of a Choice Router, having three options. The effect of using Choice router is just like adding conditional processing to a flow or an if/then/else code block in most of the programming languages. We can define choice routers as the router that dynamically routes message through a flow according to a set of DataWeave expressions used to evaluate message content. As discussed earlier, each route is a separate sequence of Mule event processors. Choice RouterĪs the name suggests, this router applies DataWeave logic to choose one of two or more routes. Choice and Scatter-Gather routers are the most used routers under Flow Control component. It is basically routing the input Mule event to other sequence(s) of components. Next, we will write the following four operations and deploy the connector to Anypoint Exchange.The main task of Flow Control component is to take the input Mule event and route it to one or more separate sequences of components. We will write all our code in the module-.xml file contained in the following folder: src/main/resources/org/mule/extensions/smart/connector. This will generate the skeleton of your project and it will look like this: Once the project is generated, you can import it into Anypoint Studio. The ArtifactId for your project or module. Generally, it should be an AnypointOrganizationId. The GroupId for your application or module. The ArtifactId of the archetype in the Mule repository. The GroupId in the Mule repository where the skeleton of the XML SDK is defined. Here is a brief description of all the attributes contained in the above command: Attributes To get started, add the below profile to the settings.xml file located in your. Errors: declares an error type that the XML SDK can raise in the body.Output: declares an output type for your XML SDK module.It executes the sequence of components, like flows. Input parameters: a set of parameters that declares the type to be entered when calling the operation.The output will then be the sum of these two numbers. It will take two parameters, and the action will be performed in the body, which will add the two numbers. For example, if you want to add two numbers, 'Add' is the operation. Operations are a type of function which takes multiple parameters, performs a given set of actions, and gives a single output. Operations: these are basically a set of parameters, the body, and the output. Here are the basic components of the new SDK: The new XML SDK is one of the easiest ways to write code for a custom connector with MuleSoft. MuleSoft created an XML SDK that lets developers write custom connectors and it's actually easier than using the Java-based Mule SDK.
0 Comments
Leave a Reply. |