DEV Community: anilkumarganna

Define and manage application metadata in MuleSoft

anilkumarganna — Wed, 05 Aug 2020 12:56:45 +0000

Data without having a context has minimal or no value. Thus, metadata provides the following context and results in playing an important role within the organization. In Mulesoft, there are two types of metadata available; structural and descriptive. The structural metadata defines the certain components and design of structured data. The descriptive metadata is a type that handles the actual data content, including the information related to invention and recognition.

Moreover, in Mulesoft, metadata offers business organizations perception into why and how the data was developed, time and date of creation, the author and location of metadata, as well as protocols that might have been used to develop it.

Mulesoft metadata propagation

One of the major aspects of explaining what comes in and what goes out is that this information is proliferated in the flow. In the Mulesoft Metadata structure at the right side of the MuleSoft Properties window, the user may find the input and output tabs. These tabs express what data flows via the Message Processor. Here, we will see the input received and expected by a connector operation and the output that the operation will generate if there isn’t an anomaly.

Thus, having all the Mulesoft metadata of the flow described will help users to understand the happenings going on at any given point.
• What data should pass via?
• What will be the output and how this moves to the next Message processor?
• What happens with the user Mulesoft Message when he adds a new
Message Processor in a flow?
• How the payload, variables, and properties are converted?
• Moreover, how all this without the need of running user application saves a lot of time?

Now, sharing this information will help other developers to understand the work performed and make it much easier to put up.

And finally, all this is chiefly helpful while modifying data structures and types using DataWeave. In case, before generating a mapping, we have to configure all the Metadata information, while adding DataWeave in the middle. Moreover, it will already know what kind of input is and what we are trying to generate as a result. Through this information, it will help us to create the script/code needed to alter the data structures and types.

All the following reasons are thinking about the Metadata while developing our MuleSoft App is useful and important.

Metadata Editor Access

Here, we will try how to access the Mulesoft Metadata editor. The following steps will help us in this regard;
• Go to the properties editor of most components and select the Metadata tab within.
• Now, on a Transform Message Component, do right-click on the input or output and select the Set Metadata option. If there is no set available, you will find a Define metadata link there.
• In case, if your input metadata is missing or inbound properties, outbound properties, session, or record variables, that you know exist in the incoming mule message. Then, can manually add them to the editor.
• Later, just do right-click on one of the categories available and select New Property or New Variable option
• Finally, on the package explorer, do right click on the project and then select Mule --> Manage Metadata types within.

Adding different Metadata types

To explicate more than one metadata type on the metadata tab within the Mulesoft app, click Add metadata. Click for one time for each metadata type you need to explain. Similarly, to remove a metadata type from the app, just click the Remove (rem icon) next to the right of the editor in the panel.

Metadata Tab basic usage

The custom metadata tab exists in all type message processors except connectors (they already put up their own metadata to DataSense). Here, the custom metadata tab enables the user to interpret metadata types for message processors. Besides, they do not automatically put up their own types.

The stated metadata types are automatically identified as inputs by the next message processor within the flow.

The user can explain the following types of input and output metadata within Mulesoft:
• Flow Vars
• SessionVars
• Message Inbound Properties
• Message Outbound Properties &
• Message Payload

Defining Metadata using UI

Here the user can develop a new metadata class with some of the available options here. While explaining the formation via the editor, the user absolutely creates a schema for that type. These schemas are stored in the user’s project’s src/main/resources folder. And the user also can open these and edit them openly on Anypoint Studio.

After the user develops a new data type, he can couple any new metadata that he creates with this new type to avoid having to explain it again.

Fixed width

The Copybook and Fixed Width are technical parts of a Flat File, and they literally construct Flat File schemas. Moreover, the Flat File type is advised only for use cases that are not included by the other two types.

Wrap an element within a collection

For any type, the user can click on the Wrap Element within a Collection checkbox. This is available at the bottom of the metadata editor window in Mulesoft app:

This sets the Mulesoft metadata as a list, where each element on the list is an example of the composition that the user defines. Thus, for example; in case we set our metadata in an XML form, clicking this checkbox will make the metadata a list that contains N mentions of that XML formation.

Reader & Writer properties

Upon the Transform Message component, there are some formats like CSV also allow users to set some additional parameters within the reader or the writer's configuration, based on if the user wants to set the input or the output.

Managing Metadata

Metadata management provides business unit awareness into their data. This allows them to give better user experience for future customers. With a Mulesoft metadata management solution, business entities can manage data, making it simpler & easier to access for future use. Finally, it promotes the reuse of data. In addition to providing a way to secure metadata, a metadata management solution allows business organizations to get metadata from applications. And utilize the same in a manner to help future application designs well. Mulesoft training offers various solutions to help organizations take the benefit of metadata in the enterprise entirely.

CloudHub Insights

Working with MuleSoft ’s integration platform as a service (iPaaS), a cloud-based platform, CloudHub Insight is a tool that gives organizations visibility towards business events and deals. Moreover, it allows them to track everything that data performs within an application. These Insights delivers searchable data to help business units answer key questions regarding their applications. Like: What happened with a specific transaction or deal? When does it occur? How long did it take to continue? What was the output?

DataSense

Acquire information about data and define methods on how to exactly map or use data in an application. Here, DataSense exchanges the task of having to manually locate information employed by the internal and external depository and resources. Moreover, the DataSense identifies and uses metadata to help business entities get the most benefit out of application integration.

Summing Up

Thus, the above article helps us to understand about metadata in Mulesoft and its management. Learn more from Mulesoft Online Training .

Property file handling in Mule Application

anilkumarganna — Wed, 01 Jul 2020 10:33:41 +0000

make life easier at all times. As for Mule, there is a nice and simple set of features to load environment-based resources. Typically, in the environment where the Mule application is being implemented, a property file is used but this includes creating several property files, one for each environment. For example, Dev, QA, SIT, and Prod. You will find a thorough guide to the method here.
Although this solution is easy to implement, it poses a challenge in that the code embeds all the configuration properties. Someone who has access to the code will be able to control all the development processes which is a condition you would really want to get into. The IT department would never send out manufacturing certificates for the Mule applications of most companies.
CI / CD best practices suggest using different properties to create a single deployable artifact that can run in all environments (dev-prod). To incorporate anything like this, an external source system such as a simple file server, SFTP, Server, or API would need to be retrieved.
In this article, you will see how Mule 4 has changed the process for managing property data. Let us cover primarily through this article.
● Newly incorporated improvements and how to deal with those improvements.
● Various proprietary hiding mechanisms in Mule 4
Properties in Mule

● You can replace Mule3's mule-deploy.properties with mule-artifact.json. Mule-artifact.json will be updated automatically when a new Mule flow is created.
● Then you can newly introduce Mule application descriptor the file mule-artificat.json. It will control all program-specific settings, Mule version, and class loader setup.
● The Mule 3 mule-config.properties file was replaced with the.yaml configuration file.
● Inputs of Mule 3's mule-app.properties have been migrated to Run Configuration-> Argument section at any point. These properties can also be configured from the runtime manager console under the Cloud hub Properties section. Image titleAdding properties ConsoleImage title runtime manager.

● Now developers will only have to keep a single file to manage program, deployment and Mule environment specific values that are not required to be part of code.
● More reliable mechanism to protect setup properties
● New feature for secure hiding of assets associated with Mule application
Configure Mule 4.X System Properties
● Build a directory with the name config in the project directory /src / main / resources.
● Build a configuration file within the newly formed configuration folder with the name configuration.yaml.
● The following screen will detail what and how the approach for property placeholders has been changed by Mule4.

Read yaml to customize the Mule Flow.
Select "Global Feature" in Mule flow, click the Create button, and select the build.yaml configuration file in step-2.
Placed holder XML configuration would look like as follows
< Doc: name="Configuration Property "doc: id="84048bfe-e690-4b64-9760-76afeb6c7860" file="config / configuration.yaml"/ >
The global HTTP listener configuration XML configuration for Mule4 in Studio 7 should appear as follows.

< http: listener = "${http.host}" port="${http.port}"/ >
< /http: konfig-listener >
To check the creation of a basic HTTP listener flow with the entries above. Place the logger to the console which prints the values.
The value of http.host will be selected from the YAML file and printed on the console after running the program.
Org.mule.runtime.core.internal.processor. LoggerMessageProcessor: > > Property Reading Values = 0.0.0.
Hiding proprietary software
Mule4 has introduced a new provision by Runtime Manager to hide the value for the property file. CloudHub supports secure hiding of Mule application properties where the name of a property is visible in the console but no user can access or retrieve the value.
Hiding System Assets via Console Configuration Manager
● Log in to the Console for Runtime Administrator
● Click on Manage Password for deployed Mule application and go to the Property tab as shown in the picture description below.
● To hide the property value, as highlighted, check the Hide values button. Enter the value and key, and click Save.
● For example, if Key = loginid and value = myloginid then hide the value specified for Key after clicking on Hide Values.
● Make sure to Redeploy Password after attaching the program from the console.
● When property values are removed from the console as hidden, their values are neither visible in the console nor transferred between the console and the server CloudHub.
Hiding User Property by configuring a user
Safely concealed Mule application properties are functionality currently only available for setting Mule applications that are deployed to CloudHub staff via the Runtime Manager UI. For Mule applications that you deploy by some other deployment technique, using protected placeholder property files that are bundled with your client zip file.
To mask Mule application property from the device configuration
Identify the property you need to cover when you deploy the Mule application to CloudHub. For example from the configuration.yaml file (shown below), I want to hide password and account while deploying my Mule application to the CloudHub.
Defined property names will be identified as a comma separate array within the mule-artifacto.json file. Image title of the Mule application as the value of the secureProperties key.
Deploy onto CloudHub Mule application. Enter Mule application property as shown in the screen below during deployment

Tap on App deploy

Mind now, as we generated two properties viz. Password and accountno hidden under mule-artifact.json, those properties should not be visible once the CloudHub Mule application has been deployed.
Once you have deployed the program, go to Manage server-> properties. No display.
It will be granted to all properties listed under secureProperties series.
Hidden properties
After committing the values and uploading the query, the securely hidden properties are never displayed on the console, nor sent and received between the console and the CloudHub server. When installed, there is no way to retrieve the house. However with a new value it can be overwritten. So, if a value needs to be modified, type a new value into the field, as shown below.
Copying Safely Hidden Mule application Properties between Sandboxes Do not copy securely hidden Mule application property values into the new environment when transferring Mule applications between sandboxes. The property name will be copied for all securely hidden Mule application properties but the value will be left blank.
Build stable, global configuration property
You can use Global Setup to build Safe Properties Configurations.
Provide location of the Properties File, Key (can be used to encrypt and decrypt the text), Algorithm (can be Blowfish), and CBC mode.
MuleSoft Components Control Safe Assets
You can access protected property in connector, DataWeave etc.
Then you can use the ${secure::propertyName} to access the property.

Backed up algorithms
● AES (default), Blowfish, Aes, RC2, RCA, and DESede.
● You can only use the following algorithms if you configure a Java Cryptography Extension (JCE) Provider that adds support to them:
● CAST5, CAST6, Noekeon, Rijndael, SEED, Serpent, Skipjack, TEA, Twofish, XTEA, RC5, and RC6.
Modes support
● CBC (Standard),
● CFB,
● ECB, and
● OFB.
Good practices
For each environment, it's recommended to keep separate properties file (e.g. appName-dev.yaml, appName-test.yaml, appName-prod.yaml).
Instead of a.properties file it is recommended to use a.yaml file.
Declaring a global property for the ecosystem is suggested (e.g., mule.env).
Do not modify the property of mule.env to prod or check but then send as an argument in the maven command of the CI / CD pipeline.
Mvn -DmuleDeploy -Dmule.env = prod deploy
Before you save them in the property register, all sensitive and confidential data such as passwords and keys need to be encrypted.
Hold all relations in global.xml, and other properties.
Now you know how to encrypt the confidential and sensitive data before saving it to Mule Properties Data.

Conclusion
I hope you reach to a conclusion about property handling in MuleSoft. You can learn more through MuleSoft online training.