Blogs
Sharing Resources Through Domain Projects in MuleSoft APM
- May 14, 2024
- MuleSoft
MuleSoft Domain Projects, a user-friendly and efficient feature, is a boon for developers seeking to streamline the management of shared resources and configurations within their on-premises Mule applications. Unlike the hassle of managing disparate configurations across various applications, domain projects provide a centralized and straightforward solution. This article delves into MuleSoft Domain Projects, covering their key components, benefits, creation process, and shared resource configuration. Whether you’re an experienced developer or new to MuleSoft services, understanding the power of domain projects is crucial for optimizing integration architecture.
What is a domain project?
A domain project is a centralized repository for configurations, policies, and shared resources, facilitating their reuse across multiple Mule applications within the same domain. It enables the establishment of universal configurations like default error handlers, properties, scheduler pools, and connector configurations. These resources, consolidated within domain projects, ensure consistency and simplify management across Mule applications. Any modifications made to shared resources within the domain project automatically propagate to all associated applications, ensuring robust system management.
Key Benefits of Domain Projects
1. Shared Resources: Domain projects allow the definition and management of common resources such as connectors, error handlers, and properties required by multiple Mule applications. By consolidating resources, domain projects ensure consistency and simplify management, with changes automatically reflecting across all associated applications.
2. Reusable Configurations: Domain projects promote component and configuration reuse, minimizing redundancy and facilitating scalability. They maintain a clear separation between shared resources and application-specific configurations, enhancing modularity and simplifying maintenance.
3. Versioning and Governance: Like other Mule projects, domain projects support versioning and governance features, enabling effective change tracking, policy enforcement, and dependency management. This ensures better consistency, reusability, and manageability, especially in environments with interconnected applications relying on common configurations and resources.
Creating a project for a sample domain
Now, let us create a project for a sample domain step wise.
Step 1: Create a Mule domain project in Anypoint Studio.
Open Anypoint Studio, click on “File”> “New”> “Mule Domain Project”. Enter your domain project name as per your requirement and click on “Finish.”
You will see a canvas like this after the project is created.
You’ve probably noticed that this canvas isn’t like a normal canvas where we create our flow, i.e., the “Message Flow” tab. Here we could not find that particular tab. Also, the underlying XML of the domain project starts and ends with “domain:Mule-domain,” whereas normal Mule XML starts and ends with the “Mule” tag.
Step 2: Configure the shared resources.
Click on the “Create” button, and you will see a window where you can search for the configurable connector.
Whenever we search for “HTTP” for the first time, we can’t find anything. So, for that, we need to click on manage modules, to load the required module, choose one of these 3 options.
- From Exchange
- From Featured Modules
- From Maven
In this demo, we are using “from Exchange”.
To activate the HTTP module, first, click “Apply” followed by “Apply and Close.” The HTTP module is automatically integrated into projects utilizing socket connectors and is also compatible with HTTP connectors. Ensure to take note of the versions of both connectors; in this instance, the socket connector is version 1.2.4, while the HTTP connector is version 1.9.2.
With the required modules enabled, proceed to click “Create” to generate shareable resources. Following this, perform another search for “HTTP.”
HTTP configurations are now accessible. To begin, establish the “HTTP listener” by selecting “HTTP Listener Config” from the window, clicking “OK,” and customizing it according to your requirements. In this scenario, default settings are applied, identifying the object as “test-domainHttpListner.”
To configure HTTP settings, begin by setting up the “HTTP listener.” Select “HTTP Listener Config” from the “Choose global Type” window, then customize the configuration to suit your requirements. For this demonstration, default settings will be utilized, and the configuration will be identified as “test-domainHttpListner_config.”
In the same way, you can configure the HTTP Request
Step 3: Let’s create a Mule API.
Create a new project by clicking on “File,” click on “New,” select and click on “Mule Project,” and then enter your domain project name as shown in the attached screenshot as “test-child.” as shown in the screenshot below.
To initiate the flow, navigate to the canvas. Prior to proceeding, ensure compatibility between the HTTP connector versions of both the calling application and the domain project. Incompatibility may result in errors, as different connector versions cannot coexist within the same project. The HTTP connector version utilized here is 1.9.2.
Begin by dragging an “HTTP listener” and an “HTTP request” connector onto the canvas, along with a “transform message” and a “logger.”
Configure the “HTTP listener” by selecting the appropriate connector configuration established in the domain project and assigning a path. In this instance, “test” will serve as the designated path.
Similarly, configure the “HTTP request” connector, selecting the appropriate configuration from the drop-down menu and making any additional adjustments necessary to interact with the API.
To retrieve the global configuration of the domain project, begin by directing it from the calling application. Right-click on the calling project, in our case “test-child-api“, proceed to “properties”, and select “Mule Project”. In the subsequent window, opt for the Domain option to select your domain API, apply the changes, and then close the window.
To view the changes made in the project, refer to the pom.xml file after accessing it through the domain API or any other applicable method.
Upon completing development, testing is the next step. You will execute the “test-child-api” calling API. The domain project need not be executed at this stage.
Now, the deployment testing can be done for the connector versions utilizing Postman. After domain initiatives have been successfully deployed and tested, data retrieval becomes feasible.
Conclusion:
MuleSoft Domain Projects empower developers with a powerful approach to managing shared resources and configurations for on-premises Mule applications. Domain projects promote consistency, streamline mulesoft development, and simplify ongoing maintenance by centralizing reusable components like connectors and error handlers. This comprehensive guide explored domain projects’ core concepts, benefits, and limitations, equipping you to leverage them effectively within your MuleSoft integration architecture.
