Notes: Module 6: Mule 3 Fundamentals: Structuring Mule Applications

Contents (on this Blog): My notes on 'Anypoint Platform Development Fundamentals (Mule 3)'

Image: Goal to simplify flows

Why?

- Easier to read

- Enables code reuse

- Provides separation between an interface and implementation

- Easier to test

6-1) Encapsulating processors into separate flows and subflows

Flows contain 3 thread pools:

- Receiving - Message source’s threads

- Flow processing - Message processor’s threads

- Dispatching - Outbound endpoint’s threads

SEDA = Staged Event Drive Architecture

- The architecture upon which Mule was built.

- Decouples receiving, processing, and dispatching phases.

- Supports higher levels of parallelism in specific stages of processing.

- Allows for more-specific tuning of areas within a flow’s architecture.

Image: Flow and Sub Flow scope

Creating flows and subflows:

- Use Flow scope to create a new flow (or drag any message processor to the canvas)

- Use Sub Flow scope to create subflows

- Use Flow Reference components to pass message to other flows or subflows

Note: Flow variables persist through all flows unless the message crosses a transport boundary.

AnyPoint Studio Canvas Notes:

Shift + Click allows selecting multiple items.

Right + Click with multiple item selected, gives option to create a Sub Flow.

6-2) Using VM endpoints in flows

The Java Virtual Machine (VM) transport:

- The JVM transport can be used for intra-JVM communication between Mule flows.

- Each app in a Mule instance has its own, unique set of VM endpoints.

- The VM transport can only handle communications within an app or between apps in the same domain.

- This transport by default uses in-memory queues but can optionally be configured to use persistent queues:

Note: VM file persistency does not work on clusters.

VM transport is (in Mule 3+) mostly used to:

- Achieve higher levels of parallelism in specific stages of processing.

- Allow for more-specific tuning of areas within a flow’s architecture.

- Call flows in other applications that are in the same domain.

Walkthrough 6-2: Pass messages between flows using the Java Virtual Machine (VM) transport

- Pass messages through an HTTP transport barrier.

- Pass messages between flows using the VM transport.

- Explore variable persistence across transport barriers.

Image: Creating Global Mule Configuration Element: HTTP Request Configuration

Image: Configuring the VM elements

6-3) Organizing Mule application files

Creating multiple applications:

- Separate functionality into multiple applications to:

--- Allow managing and monitoring of them as separate entities.

--- Use different/incompatible JAR files.

- Run more than one application at a time in Anypoint Studio by creating a run configuration.

Walkthrough 6-3: Encapsulate global elements in a separate configuration file

- Create a new configuration file with an endpoint that uses an existing global element.

- Create a configuration file global.xml for just global elements.

- Move the existing global elements to global.xml.

Image: Moving global elements to global.xml

Note: Fix to error in this lab was: Create a fake global config - e.g. ‘HTTP Request Configuration’ - then edit the XML to delete it.

6-4) Organizing Mule project files

The names of folders indicate what they should contain - schema and example files for metadata types, sample data for transformations...

src/test folders should contain files only needed at development time - they are not included in the application ZIP when it is packaged.

Walkthrough 6-4: Create a well organized Mule project

- Create a project with a new RAML file that is added to Anypoint Platform.

- Create an application properties files and a global configuration file.

- Add Java files and test resource files to the project.

- Create and examine the contents of a deployable archive for the project.

Image: Setting Property Placeholder

Image: Right-click project > Export > Mule > Anypoint Studio Project Mule Deployable Archive (includes Studio metadata)

6-5) Sharing resources between applications

Shared domains:

- Can be used to share some connectors and endpoints between applications.

- Enables multiple development teams to work in parallel using the same set of resuable resources (elements, configuration, etc.)

- Only available on-prem.

- (Currently) Only the following can be shared:

-- HTTP/HTTPS (both endpoints and connectors), WMQ, Database, JMS, VM, JBoss and Bitronix Transaction Managers

For sharing code between applications (e.g. Connector configurations, Endpoint definitions, Flows and Subflows, Transformers, DataWeave DWL files) use Maven and its dependency management mechanism!