Core Components

Like the operations in connectors and modules, Core components are important
building blocks of flows in a Mule app. Core components provide the logic for
processing a Mule event as it travels in a series of linked steps through the app.
Examples include the Scheduler, For Each, and Logger components.
o In Studio, Mule components are accessible by clicking Core from the Mule palette.

Notice that the components are subdivided into types, including Batch, Error
Handling, and Flow Control.
o In Design Center, when you are building a Mule app, you can find Mule components
listed among Modules in the Select a Component dialog.
 Design Center provides many of the Core components described below. Though the
Design Center UI does not subdivide components into the types you see in the
Studio UI, it can help to conceptualize them by those types.

Batch
To process Mule messages in batches, instead of processing them all together, you
can use Batch components, which include:
o Batch Aggregator
o Batch Job
o Batch Step
See Batch Processors.

Components
These Core components perform a variety of tasks:
o Custom Business Events: For collecting information about flows and message
processors that handle your business transactions. See also Business Events.
o Dynamic Evaluate: For dynamically selecting a script, instead of forcing you to
hardcode it through the Transform Message Component.
o Flow Reference: For routing the Mule event to another flow or subflow (and back)
within a Mule app.
o Logger: For logging important information about your Mule app, such as error
messages and status notifications.
o Parse Template: For processing a template and obtaining a result.
o Transform Message: For converting input data to a new output structure or format.
 Endpoints
Endpoints (sometimes called Sources in Studio or Triggers in Design Center) include
components that initiate (or trigger) processing in a Mule flow. The Scheduler is an
endpoint. It triggers a flow to start at a configurable interval.
Note that some connectors provide listeners that serve as endpoints. Listeners can
trigger a flow when they receive an external request. For example, an HTTP Listener
that is configured for a given URL can trigger a flow when someone or some process
goes to that URL.

Error Handling
Error handling components route and process Mule errors that occur in a Mule app:
o Error Handler
o On Error Continue
o On Error Propagate
See Error Handlers

Flow Control (Routers)

A Flow Control component (or Router) takes the input Mule event and routes it to
one or more separate sequences of components. Flow Control components include:
o Choice
o First Successful
o Round Robin
o Scatter-Gather
For example, a Choice router applies DataWeave logic to pick one of two or more
routes, where each route is a separate sequence of event processors.
A Scatter-Gather router router sends the input event to every route, and each route
independently processes the event. After every route has processed the event, the
results from all the routes are combined together into one output event.

Scopes
A Scope is a type of component that groups together a sequence of event
processors (such as other Core components and operations from both modules and
connectors) to apply some programming behavior to that isolated sequence of event
processors.
Scopes include these components:
o Async
o Cache
o Flow
o For Each
o Try
o Until Successful
For example, a Try scope lets you isolate and handle any errors that occur in a
particular sequence of flows. So, you might wrap an outbound HTTP Request
connector (and perhaps some other surrounding components before and after the
HTTP Request connector, such as a Transform Message component or a Logging
component) in a Try scope, so if an error results, you can apply logging or
compensation logic specific to that grouping of components. See Try Scope.
Another example is the For Each (or Foreach) scope, which takes a collection of
data, usually extracted from the current input event, and applies the same sequence
of event processors to every item in the collection. For example, a For Each scope
might be used to process each individual row returned from a database query or
each individual line from a CSV file. See For Each Scope.

Transformers
Transformers are components you can use to set or remove a part of the Mule
event. Transformers include:
o Remove Variable
o Set Payload
o Set Variable

What is a Center for Enablement

(C4E)?
Technology is important to enterprise success. But the larger a company becomes
and the more technology projects it initiates, the more complexity and fragmentation
arise in both business processes and the tech landscape. To deal with this difficult
environment, companies often introduce rigorous management and control
processes, but these can become overly rigid and calcify innovation and agility.

Businesses need a way to introduce processes and manage change to make sure
that IT projects don’t proliferate in the shadows. At the same time, they must keep
the road smooth for innovation throughout. Believe it or not, these seemingly
irreconcilable goals can coexist.

The principles behind a C4E

A Center for Enablement (C4E) is a group that drives the IT operating model shift. It’s
in charge of enabling business divisions – including (but not exclusively to) IT – to
build and drive the consumption of assets successfully, enabling speed and agility. It
allows the business and IT teams to shift from a production-based to a production-
and-consumption-based delivery model.

The C4E is a cross-functional team typically staffed with members from central IT,
line-of-business (LoB) departments, and digital innovation teams who are charged
with productizing, publishing, and harvesting reusable assets and best practices.
They promote consumption and collaboration and help drive self-reliance while
improving results through feedback and metrics. Overall, the primary goals of the
C4E are to run the API platform and enable teams on how to best use it while
developing reusable APIs to accelerate innovation and deliver change more
efficiently.

The naming convention for C4E might recall a familiar concept: the Center of
Excellence (CoE). However, a C4E is a radically different idea. Traditional CoEs,
responsible for running an API platform, developing APIs, and managing their
operation, feature centralized expertise and knowledge, resulting in information
being unintentionally protected and rationed. CoEs often present several challenges,
such as becoming bottlenecks that developers and architects work around,
increased inefficiency, and preventing consumers from experimenting. The below
graphic provides a further overview of additional differences between a C4E and a
CoE.
How to set up a C4E
There are six steps required to set up a C4E:

1. Assess the organization’s integration capability: It’s important to understand your

organization’s current integration and API capabilities as well as the maturity of the
business in terms of strategy, organization, community, governance, architecture,
and project delivery.
2. Establish the C4E operating model: If you determine that your organization will adopt
the C4E model, you must decide on roles and responsibilities within the C4E, define
 KPIs for measuring developer engagement, productivity, and consumption, and
more.
3. Building and publishing foundational assets: Then, the organization will need to build
an engagement layer for developers and architects alike. This involves building and
publishing an initial set of reusable assets, such as API fragments, API specs,
templates, etc.
4. Evangelizing the C4E: In this step, the core C4E team will need to promote and
evangelize C4E across the organization. After all, the principles of reuse and self-
service that a C4E promotes won’t mean much if the organization doesn’t know
about or use them.
5. Driving consumption of assets: Once a C4E becomes common knowledge across the
organization, the C4E core team’s next job is to encourage and drive consumption of
reusable assets. This can be done in various ways from onboarding and enabling
project teams to encouraging dialogue among teams and incentivizing reuse
through KPIs.
6. Measure C4E KPIs: Key Performance Indicators (KPIs) help to measure the
effectiveness of a C4E. C4E’s success is directly measured against the consumption
and reuse of the assets and how it accelerates the delivery of business outcomes.

Benefits of a C4E
Some expected benefits of building a C4E include:

 Shorter delivery cycles, including faster time to market for your integration projects
through reuse and self-service 
 Reduced project risk and on-time delivery of integration projects 
 Better adherence to standards and best practices 
 Higher quality deliverables due to being built on existing templates and APIs,
reducing the number of defects and error rates 

The bottom line is that with these outcomes, our customers deliver projects 3x faster
and increase team productivity by 300% more than other approaches.

Digital transformation with a C4E

To achieve true digital transformation, people and processes are just as important to
the journey as technology. Like any dramatic transformation process, digital
transformation has to include a new way of thinking. You can’t expect to transform if
you do things the same old way.

And ultimately, building a C4E is one way companies like Unilever and Coca-Cola
have achieved greater agility and productivity. 

Ready to get started? For more resources on how a C4E could help your
organization, check out our whitepaper on how to rethink IT’s function in your
company.