Traits is like function and is used to define common attributes for HTTP method (GET, PUT, POST, PATCH, DELETE, etc) such as whether or not they are filterable, searchable, or pageable.

Example :

Example :

Example :

Example :

API Autodiscovery is a mechanism that manages an API from API Manager by pairing the deployed application to an API created on the platform.

API Management includes tracking, enforcing policies if you apply any, and reporting API analytics. Critical to the Autodiscovery process is identifying the API by providing the API name and version.

The configuration can be modified in the servers /conf/wrapper.conf file

API proxies, also known as "autogenerated proxies", are meant to enhance the usability of API Manager in your Mule application.

Typical usage: Either when we want to leverage API Gateway capabilities and our backend API is not based on Mule Runtime, or when our API is based on Mule Runtime but you are unable to define the corresponding Autodiscovery element because it is a closed code.

• API Manager
  • API manager is there to create and configure APIs but Rumtime will host application i.e. nothing but Cloudhub having Mule runtime.
  • In API Manager 2.x, we can use instances of an API in multiple environments, and we can have multiple instances in the same environment.
  • Through the Autodiscovery scheme, API Manager can track the API throughout the life cycle as you modify, version, deploy, govern, and publish it.
  • API Manager 2.x is tightly integrated with the following tools:
    1. Design Center for creating the RAML structure of the API :- The API design capabilities of Design Center replace the Jul 2017 API Designer tool in Anypoint Platform.
    2. Exchange for storing and publishing API assets :- Assets are components, such as API versions, templates, and connectors owned by MuleSoft or your organization.
    3. Studio for implementing the API :- API changes made in Studio are synchronized using Autodiscovery with the API registered in other tools, such as Design Center and API Manager.
• Runtime Manager
  
  • The Runtime Manager REST API enables us to programmatically access these functions of Runtime Manager:
    •   Manage servers:
      1. Register a server.
      2. Get a list of registered servers.
      3. Get information about a server.
      4. Change the server name.
      5. Shut down, restart, or delete a server.
      6. Renew server certificates.
      7. Get a server registration token.
    •   Manage server groups:
      1. Create a server group from a list of servers.
      2. Get a list of registered server groups.
      3. Get information about a server group.
      4. Change the server group name.
      5. Add or remove a server from a server group.
      6. Delete a server group.
    •   Manage clusters:
      1. Create a cluster.
      2. Get a list of registered clusters.
      3. Get information about a cluster.
      4. Change the cluster name.
      5. Add or remove a server from a cluster.
      6. Modify clustering information for a server.
      7. Delete a cluster.
    •   Manage app deployments on your servers:
      1. Deploy, redeploy, and undeploy apps.
      2. Get application deployment and status information.
      3. Manage flows, schedulers, and alerts in a deployed app.

From a business point-of-view, scalability is the ability to serve customers seamlessly even when a sudden change in demand occurs.

From an IT point-of-view, scalability is the ability to add/remove infrastructure resources needed by business applications to manage the increased/decreased demand in the number of business transactions.

There are three types of scalability options:

1. Vertical scale or scale-up: Adding more compute or memory resources for your applications increases the maximum capacity of the server. When demand spikes, there should not be any noticeable change to your applications.
2. Horizontal scale or scale-out: Adding more individual servers into a resource pool where your applications run.
3. Diagonal scaling: Essentially a combination of vertical and horizontal scaling, this setup will scale vertically first until you reach a preset limit and then scale the system horizontally.

•   Rate Limiting:
  • The Rate Limiting policy limits the number of requests an API accepts within a window of time.
  • The API rejects requests that exceed the limit. You can configure multiple limits with window sizes ranging from milliseconds to years.
•   Throttling:
  1. The Throttling policy queues requests that exceed limits for possible processing in a subsequent window.
  2. The API eventually rejects the request if processing cannot occur after a certain number of attempts. You can configure a delay between retries, as well as limit the number of retries.
•   Rate Limiting (SLA-Based):
  1. The Rate Limiting policies based on a service level access (SLA) are client ID-based policies that use the client ID as a reference to impose limits on the number of requests that each application can make within a period of time.
  2. To use these policies you need to create at least one SLA tier to define request limits.
The Rate Limiting and Throttling policies impose a limit on all requests or a specific resource (in Mule 3.x and earlier, the API must be APIkit-based).

The service level access (SLA)-based Rate Limiting and Throttling policies add further granularity, limiting requests by the level of access granted to the requesting application.
Rate Limiting and Throttling policies are designed to limit API access, but have different intentions: Rate limiting protects an API by applying a hard limit on its access. Throttling shapes API access by smoothing spikes in traffic.

An object store is a facility for storing objects in Mule. Mule uses object stores whenever it needs data to persist for later retrieval. Internally, Mule uses object stores in various filters, routers, and other message processors that need store their state between messages. In most cases, Mule creates and manages object stores automatically, so no user configuration is necessary.

Mule provides two types of object stores for non-clustered servers:

1. in-memory store :- Mule persists data by default.
2. persistent store :- Mule persists data when an object store is explicitly configured to be persistent. Mule creates a default persistent store in the file system.

Namespace -> xmlns:objectstore="http://www.mulesoft.org/schema/mule/objectstore"

Dependency Details -> <dependency> <groupId>org.mule.modules</groupId> <artifactId>mule-module-objectstore</artifactId> <version>2.0.0</version> </dependency>

The Object Store connector is an operation-based connector : Contains, Dual Store, Remove, Retrieve, Retrieve All Keys, Retrieve And Store, Store.

•   Contains:
  1. Checks whether the object store contains the given key.
  2. <objectstore:contains key="MUL0001" config-ref="config-name"/>
  3. Return boolean :- true if the object store contains the key, or false if it doesn't.
•   Dual Store:
  1. Stores a value using key and also stores a key using value. If an exception is thrown rolls back both operations. This allows an option to indicate if key would be overwritten or not.
  2. <objectstore:dual-store key="MUL0001" value-ref="#[string:Ankur Bhuyan]" config-ref="config-name"/>
  3. Return boolean :- true if you want to overwrite the existing object.
•   Remove:
  1. Remove the object for the respective key. This operation can fail silently based on the value passed in ignoreNotExists.
  2. <objectstore:remove key="MUL0001" config-ref="config-name"/>
  3. Return Serializable :- The object that was previously stored for the given key. If the key does not exist and ignoreNotExists is true the operation will return a null object.
•   Retrieve:
  1. Retrieve an object from the object store and make it available in the specified property scope of a Mule Message.
  2. <objectstore:retrieve key="MUL0001" defaultValue-ref="#[string:Ankur Bhuyan]" config-ref="config-name"/>
  3. Return Serializable :- The object associated with the given key. If no object for the given key was found this method throws an ObjectDoesNotExistException.
•   Retrieve All Keys:
  1. Returns a list of all the keys in the object store.
  2. <objectstore:retrieve-all-keys>
  3. Return List(String) :- a java.util.List with all the keys in the store.
•   Retrieve And Store:
  1. Retrieve and Store in the same operation.
  2. <objectstore:retrieve-and-store>
  3. Return Serializable :- The object associated with the given key. If no object for the given key was found this method returns the defaultValue.
•   Store:
  1. Stores an object in the object store. This allows an option to indicate if key would be overwritten or not.
  2. <objectstore:store key="MUL0001" value-ref="#[string:Ankur Bhuyan]" config-ref="config-name"/>
  3. Return boolean :- True if you want to overwrite the existing object.

•   Stands for:
  • DDL : DDL stands for Data Definition Language.
  • DML : DML stands for Data Manipulation Language.
•   Usage:
  • DDL : DDL statements are used to create database, schema, constraints, users, tables etc.
  • DML : DML statement is used to insert, update or delete the records.
•   Classification:
  • DDL : DDL has no further classification.
  • DML : DML is further classified into procedural DML and non-procedural DML.
•   Commands:
  • DDL : CREATE, DROP, RENAME and ALTER.
  • DML : INSERT, UPDATE and DELETE.

The $ symbol can be used for accessing the VALUE of a key-value pair in a map.

$$ can be used for getting the KEY (or index) of the key-value pair.

• This connector provides Secure HTTP connectivity on top of what is already provided with the Mule HTTP Transport.
• Secure connections are made on behalf of an entity, which can be anonymous or identified by a certificate.
• The key store provides the certificates and associated private keys necessary for identifying the entity making the connection.
• Additionally, connections are made to trusted systems.
• The public certificates of trusted systems are stored in a trust store, which is used to verify that the connection made to a remote system matches the expected identity.

Example : <https:connector name="httpConnector"> <https:tls-client path="clientKeystore" storePassword="mulepassword"/> <https:tls-key-store path="serverKeystore" storePassword="mulepassword" keyPassword="mulepassword"/> <https:tls-server path="trustStore" storePassword="mulepassword"/> </https:connector> <https:endpoint name="clientEndpoint" host="localhost" port="60202" connector-ref="httpConnector" />

1. In order to setup a HTTPS server with Mule a few first steps need to be performed. First a keystore must be created, this can be done using the keytool provided by Java. You can find this in the bin directory of the Java installation.
   Once located you can then execute the following command to create a keystore: keytool -genkey -alias mule -keyalg RSA -keystore keystore.jks
2. This will create a file in the local directory called keystore.jks
   Ideally this should be created in the MULE_HOME/conf directory if to be used across multiple applications or can be put into the MY_MULE_APP/src/main/resources directory if being used within a single application.
3. If the keystore was in the MY_MULE_APP/src/main/resources directory then you can just specify the name in the path.
   Otherwise if the keystore was located in the MULE_HOME/conf directory then you will have to specify "${mule.home}/conf/keystore.jks" as the path.
4. Configuration Reference :
   • tls-client :
     Configures the client key store with the following attributes:
     1. path: The location (which will be resolved relative to the current classpath and file system, if possible) of the keystore that contains public certificates and private keys for identification
     2. storePassword: The password used to protect the keystore
     3. class: The type of keystore used (a Java class name)
   • tls-key-store :
     Configures the direct key store with the following attributes:
     1. path: The location (which will be resolved relative to the current classpath and file system, if possible) of the keystore that contains public certificates and private keys for identification
     2. class: The type of keystore used (a Java class name)
     3. keyPassword: The password used to protect the private key
     4. storePassword: The password used to protect the keystore
     5. algorithm: The algorithm used by the keystore
     6. keyAlias: The alias of the key to use
   • tls-server :
     Configures the trust store. The attributes are:
     1. path: The location (which will be resolved relative to the current classpath and file system, if possible) of the trust store that contains public certificates of trusted servers
     2. class: The type of trust store used (a Java class name)
     3. storePassword: The password used to protect the trust store
     4. algorithm: The algorithm used by the trust store
     5. factory-ref: Reference to the trust manager factory
     6. explicitOnly: Whether this is an explicit trust store
     7. requireClientAuthentication: Whether client authentication is required
   • tls-protocol-handler : Configures the global Java protocol handler. It has one attribute, property, which specifies the java.protocol.handler.pkgs system property.

Using HTTP Requester

• REGRESSION TESTING :
  
  • REGRESSION TESTING is defined as a type of software testing to confirm that a recent program or code change has not adversely affected existing features.
  • Regression Testing is nothing but a full or partial selection of already executed test cases which are re-executed to ensure existing functionalities work fine.
  • This testing is done to make sure that new code changes should not have side effects on the existing functionalities. It ensures that the old code still works once the latest code changes are done.
• BLACK BOX TESTING :
  
  • BLACK BOX TESTING, also known as Behavioral Testing, is a software testing method in which the internal structure/design/implementation of the item being tested is not known to the tester. These tests can be functional or non-functional, though usually functional.
  • This method attempts to find errors in the following categories:
    1. Incorrect or missing functions
    2. Interface errors
    3. Errors in data structures or external database access
    4. Behavior or performance errors
    5. Initialization and termination errors
  • Types of Black Box Testing : There are many types of Black Box Testing but the following are the prominent ones -
    1. Functional testing - This black box testing type is related to the functional requirements of a system; it is done by software testers.
    2. Non-functional testing - This type of black box testing is not related to testing of specific functionality, but non-functional requirements such as performance, scalability, usability.
    3. Regression testing - Regression Testing is done after code fixes, upgrades or any other system maintenance to check the new code has not affected the existing code.
  • Tools used for Black Box Testing : Tools used for Black box testing largely depends on the type of black box testing you are doing -
    1. For Functional/ Regression Tests you can use - QTP, Selenium
    2. For Non-Functional Tests, you can use - LoadRunner, Jmeter

• Modem
  • Stands for "modulating-demodulating".
  • A modem is often provided by your ISP (Internet Service Provider) which enables a network access to the internet.
  • Modems are hardware devices that allow a computer or another device, such as a router or switch, to connect to the Internet. They convert or "modulate" an analog signal from a telephone or cable wire to digital data (1s and 0s) that a computer can recognize.
  • Simply send traffic from point A to piont B without further manipulation.


• Routers
  
  • Are responsible for sending data from one network to another.
  • When connecting more than one device to a modem, a router is generally required. A router acts as the “traffic director” of a network.
  • Work at Layer 3 (Network) of the OSI model, which deals with IP addresses.
  • Typically, routers today will perform the functionality of both a router and a switch - that is, the router will have multiple ethernet ports that devices can plug into.


• Switches
  
  • They use the MAC address of a device to send data only to the port the destination device is plugged into.
  • Work at Layer 2 (Data Link) of the OSI model, which deals with MAC addresses.
  • A switch (such as a 10GbE switch or Gigabit PoE switch) is used to provide additional ports, expanding the capability of the router.

•   What Is ResourceTypes?
  • ResourceTypes is like resource in that it can specify the descriptions, methods, and its parameters. Resource that uses resourceTypes can inherit its nodes. ResourceTypes can use and inherit from other resourceTypes.
  • In order to implement the patterns found in the API, resource types use reserved and user-defined parameters surrounded by double angle brackets (<< and >>).
  


•   What Is Traits?
  • Traits is like function and is used to define common attributes for HTTP method (GET, PUT, POST, PATCH, DELETE, etc) such as whether or not they are filterable, searchable, or pageable.
  • Whereas a resource type is used to extract patterns from resource definitions, a trait is used to extract patterns from method definitions that are common across resources.
  

• map :
  
  • It returns ARRAY.
  • Syntax :
    • map(Array < T >, (item: T, index: Number) -> R): Array < R >
    • map(Null, (item: Nothing, index: Nothing) -> Any): Null
• mapObject :
  
  • It returns Object.
  • Syntax :
    • mapObject({ (K)?: V }, (value: V, key: K, index: Number) -> Object): Object
    • mapObject(Null, (value: Nothing, key: Nothing, index: Nothing) -> Any): Null
• flatten :
  
  • It returns ARRAY.
  • Syntax :
    • flatten(Array< Array < T > | Q>): Array < T | Q >
    • flatten(Null): Null

Any data Types in RAML is define under types: section.

Example:

We can define number of security patterns under is section using Square brackets "[]" separated by comma.

Example:

By default these THREE pools available in Mulesoft containers.

• CPU_LITE
• CPU_INTENSIVE
• BLOCKING_IO

Apart from these THREE pools we have TWO custom containers.

• GRIZZLY(Shared) - Custom
• GRIZZLY(Dedicated) - Custom

Read about "API Led Architecture" from one of blog here.

1. Using a inbound connector in "source" section of a flow.
2. Using "flowref" from other flow/sub-flow.
3. Using "VM" component from other flow/sub-flow.
4. Using "batch" component in "source" section of a flow.

• In simple terms, authentication is the process of verifying who a user is, while authorization is the process of verifying what they have access to.
• Authentication is the process of verifying an identity (who they say they are).
• Authorization is the process of verifying what someone is allowed to do (permissions).

•   Pros and Cons of GitHub
  
  • Pros
    
    • Amazing system for the open-source codebase
    • Allows easy sharing
    • Has a sophisticated and user-friendly UI
    • Offers pull requests and comments
    • Has a large community
    • Easy setup
    • Allows remote collaboration
    • Provides with easy control features
  • Cons
    
    • Doesn’t offer very good API development
    • Slightly expensive for those in search of private repository
    • It is not very features


•   Pros and Cons of GitLab
  
  • Pros
    
    • Has a consistent addition of new features
    • Offers pull requests and code reviews
    • Has a CLI user experience
    • Offers package management
    • Supports CI/CD lifecycle
    • Easy maintenance of codes
  • Cons
    
    • Problematic upgrade process
    • Lacks some enterprise-level features
    • Has quite a lot of bugs
    • Small community

Foreach is more reliable but it process records iteratively using single thread ( synchronous), hence parallel processing is not possible. Each records creates a single message by default.

Batch processing is designed to process millions of records in a very fast and reliable way. By default 16 threads will process your records and it is reliable as well.

TODO : Will update in future

JMS, JDBC, VM

Based on project and customer requirement the Tests phases can be differ. A sample life cycle could be like this :

Unit Test -> Integration Test -> Functional Test -> Performance Test -> Regression Test -> User Acceptance Test -> API Security Test -> Smoke Test

The build Maven Life Cycle is divided into 3 types, they are:

1. Default Lifecycle
2. Clean Lifecycle
3. Site Lifecycle

The phases of Default Life Cycle are:
validate -> compile -> test -> package -> integration-test -> verify -> install -> deploy

skipNullOn="everything"

The difference between a refresh token and an access token is the audience: the refresh token only goes back to the authorization server, the access token goes to the (RS) resource server.