DevoteamInsightsBlog Series, Part II: How does MuleSoft (iPaaS) help to grow your organisation as an Integration Platform

Blog Series, Part II: How does MuleSoft (iPaaS) help to grow your organisation as an Integration Platform

Author

  • Pavan Kumar
    Senior Integration Developer | MuleSoft Mentor

Share
Change Salesforce
In the part one of this blog series, we have seen and discussed the various Integration styles and types that can be used to provide the most appropriate solution depending on the requirements. Imagine getting all of these as a service? Well imagine no more as with Integration Platform as a Service (iPaas) you have that service and this is Mulesoft.
  • MuleSoft is an Integration Platform that can offer all ESB solutions, it has the implementations for the majority of the patterns in Enterprise Integration. 
  • MuleSoft has a cloud Integration Platform as a Service (iPaaS) called Anypoint Platform which has multiple web applications with which customers can Develop/Deploy/Maintain their APIs. It allows both MicroServices and ESB solutions,  which in turn enables you to produce solutions for the full lifecycle of APIs/Integrations.
  • It offers applications listed below:
    • API Designer – to develop the APIs in RAML language
    • API Exchange – enables the customers to auto-discover their APIs/artefacts via the service exchange in order to easily discover the organisation artefacts 
    • Runtime Manager – to deploy the APIs to targets(Cloud/OnPremises/Private Cloud etc)
    • Anypoint MQ – The queueing solution being offered  
    • Visualizer – to visualise the API/applications overall network to the customers
    • Monitoring – to Monitor the APIs/applications performance in a reliable manner 
    • Secrets Manager – to keep your APIs/applications secret files like the certificates/keystore etc and maintain them securely
    • It has readily available use case-driven accelerators to enhance the speed of development by increasing the ease of your Integration architecture and design development. 
  • MuleSoft offers its products and services as different deployment models 
    • Cloud-based 
    • On-Premises 
    • Containerized environments
    • Hybrid etc. 
    • To know more on this – See below link or talk to us https://docs.mulesoft.com/runtime-manager/deployment-strategies
  • From an ESB perspective, MuleSoft has almost all implementations of well-known EAI (Enterprise Application Integration) patterns readily available to be used by developers in developing effective integrations.  You can check them in the MuleSoft concepts
    https://docs.mulesoft.com/mule-runtime/4.1/mule-concepts
  • Reliability, by aspiring to have zero message/data loss after a Mule application stops or crashes. Usually, to develop the reliable integrations you could leverage certain best available reliability patterns such as below:
    • Until Successful scopes 
    • Reconnection strategies 
    • Redelivery policy 
    • Transactions 
    • MULE:REDELIVERY_EXHAUSTED error type handle.
    • If the Mule application does not have one transactional component in it being used, then we can use the reliability pattern flow by decoupling it from the actual main flow to any vendor queuing Queue/VM Queue in Mule runtime as well.  Please check the link below for more information
      https://docs.mulesoft.com/mule-runtime/4.4/reliability-patterns
  • High Availability, by keeping the overall system operational when a system component fails. To develop the Integrations/Solutions against this problem in MuleSoft we have certain ways according to the deployment model explained below:
    • Horizontal scaling – in Cloud/Runtime Fabric
    • Load Balancing and/or Clustering in On-Premises (in-house)
  • To develop the future-proofed ESB Integration/Microservices software solutions, identifying the right patterns and the components to be used within the MuleSoft platform is of the utmost importance. Should you need support from MuleSoft experts in doing this then please get in touch.
  • Speed of Delivery & Return on Investment(ROI)
    • As we discussed in our part 1 blog, how Point-to-Point integration can easily lead to disaster for organisations. There are many ESB pattern solutions that can be followed. On top of this, MuleSoft has also developed its own approach to tackling this problem with its own style of using Microservices in a method known as “API Led Connectivity”
    •  API Led Connectivity is a methodical approach of MuleSoft to connect the data to systems in a reusable and purposeful manner. The APIs are divided into 3 layers wherein each layer provides a different purpose. 
API layers and their purposes

  • We encourage you to adopt the API Led Connectivity approach so that everyone in the entire organisation can get the best capabilities in delivering the applications. 
  • The diagram above shows how the 3 categories of Experience / Process / System layers are divided in the organisation. 
    • Experience – To serve the Customer needs
    • Process – The process orchestrations and business implementations
    • System – Unlocking the data from the Systems.
  • API Led Connectivity not only means categorising the APIs into 3 layers and reusing the APIs to compose new capabilities but also decentralises the access to Organisation assets. 
  • Central IT produces the reusable assets in the process of unlocking the key systems like legacy systems/ DataSources / SaaS applications etc. Central IT and other teams then re-use these assets and compose their process-level assets. 
  • The application developers can then discover these assets and self-serve all of them, thus increasing the speed of the delivery and productivity of the organisation. 
  • The Return on Investment here refers to how far we are able to manage our entire organisation assets without rewriting the same assets again and again without knowing that it exists. It may look simple, but when the organisation grows and keeps on building the APIs/Integrations with help of different teams,  it can easily happen unknowingly. The C4E(Centre for Enablement) team in the API Led Connectivity model is very helpful here. To understand this clearly let’s take an example of an Acme Clinic.
    • Acme Clinic has a requirement of creating a portal in Salesforce for their patients to be able to register for appointments with the GP. 
    • The team has built their portal in Salesforce and the backend database is then integrated using MuleSoft Integration based on the API Led Connectivity model.  The following 3 APIs are then put into the exchange.
      • Salesforce ClinicPortal Experience API
      • Patients Process API 
      • AcmeDB SYstem API 
API Led Connectivity model
  • The Acme Clinic then creates another requirement to manage the misplaced registrations or to change the details of the registrations. To do that, they can simply reuse the existing APIs by enabling the experience API to communicate with the Admin System as follows:
    • Admin Experience API
Admin Experience API

  • As a result, the speed of the next use case or project delivery is going at a fast pace that is meeting or exceeding the expectations of the Customer. 
  • Above is a simple example but you may find that you have many more systems you wish to integrate and have questions on how to manage these integrations. If you do and want to speak to experts in this field then please contact us.

If you want to get back to the first part of this topic, you can use this link.

References: