API Security

API is a key component of digital transformation. API is the interface of your legacy and SAAS data. The goal of APIs is to facilitate the transfer and enablement  of data between your system and external users. APIs are typically available through public networks like the internet to communicate to external users and expose your data into the public domain.

Since your data is exposed into the public domain through APIs, It can lead to a data breach. APIs can be broken and expose sensitive personal as well as company data. An insecure API can be an easy target for hackers to gain access to your system and network. Rise of IOT devices and usage of APIs by these IOT devices, APIs are now more vulnerable. 

According to owasp, these are 10 main API vulnerabilities.

  1. Broken Object Level Authorization – Expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue.
  2. Broken User Authentication – Authentication mechanisms are implemented incorrectly.
  3. Excessive Data Exposure – Developers  expose all object properties without considering their individual sensitivity
  4. Lack of Resources & Rate Limiting – APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user, lead to Denial of Service (DoS) attack on APIs
  5. Broken Function Level Authorization Complex access control policies with different hierarchies lead to authorization flaws.
  6. Mass Assignment – Without proper properties filtering based on an allowlist, usually leads to Mass Assignment.
  7. Security Misconfiguration – Misconfiguration or lack of Security configuration  is commonly a result of insecure APIs
  8. SQL Injection SQL Injection occurs when untrusted data is sent to an interpreter as part of a command or query.
  9. Improper Assets Management – APIs tend to expose more endpoints than traditional web applications lead to improper expose APIs.
  10. Insufficient Logging & Monitoring – Insufficient logging and monitoring fail to find your vulnerability and broken integration.

How to mitigate API security risk?

  • API supports secure sockets layer (SSL), transport layer security (TLS), and Hypertext Transfer Protocol Secure (HTTPS) protocols, which provide security by encrypting data during the transfer process.
  • Apply Basic Auth minimum with API or  if you want to more secure your API then enable 2 way authentication through OAuth framework . 
  • Apply Authorization on each API resource to more control on API security through external Identity and access management provider (IAM).
  • Use encryption and signatures to all your API exposed personal and organizational sensitive data.
  • Apply API throttling through API manager to control number of user access per API (Rate Limiting).
  • Implement best practice of exception handling on your APIs to hide all your internal server and database information to mitigate SQL injection security risk.
  • Use Service Mesh to manage different layers of API management and control.
  • Audit your APIs and remove all unused API from your API catalog.
  • Add proper logging, Monitoring and Alerting on your APIs to keep track of your APIs activity.

Conclusion: APIs are a critical part of modern AI, mobile, SaaS, IOT and web applications. APIs Security should be the main focus on strategies and solutions to mitigate the unique vulnerabilities and security risks .

Covid 19 :Digital Transformation

Digital Transformation

The coronavirus (COVID-19) outbreak is one of the worst pandemic in recent history. This pandemic is affecting almost every person in the world. This pandemic is changing our living style, working style and also affecting our society.

This pandemic crisis raised a number of unique challenges among small and enterprise businesses. Organizations are navigating the business and facing unique operational challenges and delivering their product to their customers during the pandemic. 

During this COVID-19 pandemic crisis here are few business challenges 

  • Resource Management 
  • Client Management 
  • Digital/online transformation 
  • Employee Remote work management

In this pandemic crisis API is playing a pivotal role to help their customers to migrate their business into digital through digital transformation solutions. API is playing a pivotal role to expedite digital transformation. API is also providing a platform  and solution for crisis management during this pandemic.

Here is API solution for business

  • Make decisions — APIs are creating open platforms that expose critical COVID and organization data to enable organization proper management and tracking.These API enable data are helping to create dashboard and AI model. These dashboard and AI models help organizations to  take decision or forecast their future strategy.
  • Respond and deliveries — Tracking and Management APIs are  enabling organizations to respond quickly for any crisis and deliver their product on time.This helps any organization to expand their business and digitalize their legacy system & assets.
  • Return to work — APIs, templates and connectors are helping to unlock employee data. Organizations are integrating with ERP systems through APIs and unlocking their employee and resources data during pandemic. It is also facilitating/helping their employees to return their work during pandemic time either remote or onsite.
  • Simplify delivery — Enabling APIs, templates and micro-services are helping to simplify and  improve their business process during pandemic.This is also helping to enable new innovation within organization and opening new business opportunity.

Covid 19 is also expediting digital transformation in healthcare. It is reshaping the way humans interact with technology in healthcare and Public Health Agencies  or Federal Regulators. COVID-19 is also pushing healthcare organizations to embrace the idea of digital health and intelligent data integration as a tool. “Contact tracing” during pandemics is only possible through enablement of APIs. Federal and state governments are getting “contact tracing” patient data through API and using this data to trace down the source of pandemic.

API is also enabling pharmaceutical industries to deliver medicine fast and on time. It is also helping to manage and track medicine dose and availability. 

Conclusion: Covid is disrupting whole industries and pushing companies to digital transform their process forever.

Mulesoft Performance Tunning

API Performance Tunning
  1. Keep the application synchronous if possible. Synchronous flows avoid serialization/deserialization of messages sent through VM queues, do not cause context switches, and do not cause contention when messages move across thread pools.
  1. Store as little as possible in variables. The vars are serialized and deserialized every time a message crosses an endpoint, even if it is a VM endpoint. This will impact performance overhead in direct proportion to the size of variables and the number of endpoints. 
  1. Use Dataweave Java payloads whenever possible. The usage of a canonical data model is recommended for projects that deal with data (mapping, transformation etc.). It is also recommended to create them in Java objects as dataweave whenever possible, as this provides the fastest format to access fields and change information and to convert to other formats.
  1. Encourage dataweave  languages. For better performance, use Dataweave for simple data extraction from messages, and Java components with dataweave for everything else. 
  1. Use flow references instead of VM endpoints. To communicate between flows internally within an application, use flow references instead of VM endpoints. The VM connector, even though it is an in-memory protocol, emulates transport semantics that serialize and deserialize parts of your messages, most notably the vars. This makes it slower than a flow reference, which just injects messages into the referenced flow with no intermediate steps. Please note that in some cases the usage of VM endpoints is preferred (see the chapter on reliability patterns). For example, a Mule cluster can load balance applications that use VM endpoints by deferring execution to another, available node in the cluster.
  1. Cache aggressively. Take advantage of Mule’s caching scope when making requests to external resources like Web services or databases. Also consider caching reusable assets such as security tokens or ephemeral API keys and cookies. Mule’s Notification subsystem can additionally be used to “warm up” a cache when Mule starts. For example, consider doing this for situations where an initial cache miss is not acceptable.
  1. Configure message processors and endpoints at the global level. Some connectors allow you to configure some parameters at both the global and the endpoint/message processor level. We recommend placing the configuration at a global level to avoid repeated initialization of resources. 
  1. Avoid creating a large volume of business events. Business events incur performance overhead in Mule and in platform when platform’s internal event buffer overflows. Thus, avoid using either default flow level business events or a large volume of custom business events in a high message volume project.
  1. Consider using message compression. For communicating between Mule applications over the network consider using Mule’s compression processors to compress/decompress the message payloads before they hit the wire if their sizes are large.
  1. Consider using VM queues instead of an external message broker. VM queues are fast and have some guaranteed delivery semantics in a cluster. Consider using these instead of going out to an external messaging broker for inter-application Mule communication.
  1. Use the async scope when appropriate. If a flow is performing processing on a message that is neither modifying the message nor changing how it is routed, then it could be wrapped in an async block. This will cause the processing to occur in a different thread and will avoid adding unnecessary overhead to processing the message.
  2. Use connection pooling for connectors because the performance cost of establishing a connection to another data source, such as a database, is relatively high.
  3. Optimize your logging within your mule flows. Too much logging will slow down your process and too less logging will hard to debug.
  4. Encryption and decryption of data is very costly. Whenever your Mule application really needs then apply encryption/decryption on your data.

APIs Integration with IOT and CRM improves Customer Service

APIs integration helping IOT and CRM to enable better customer experience

IOT (Internet of things) is revolutionizing our lives. As per Gartner report by 2025 IOT market will expand a 58-billion-dollar opportunity. It is affecting all parts of our life. In our pandemic era we found more use of IOT device to maintain social distancing.

IOT is also one of the main disruptive technologies in our businesses. It is affecting all business domain including healthcare, retail, automotive, security.

There are wide range of IOT benefits in business.

  • Enhanced productivity
  • Better customer experience
  • Cost-effectiveness

CRM system is keeping all your customer relationship like data, notes, metrics and more – in one place. CRM is helping small business to take off all burden from the IT management team by automating the business process. It is also helping employee to keep the focus on the critical business areas.

API is helping to integrate these two unrelated systems. APIs are enabling this system to optimize process and streamline whole business process. API is the main communication channel to build robust process and keeping real time update to these systems. APIs are allowing to build context-based application with IOT and CRM to interact with the physical world.

Now here are few areas where IOT is helping CRM system with help of APIs to optimize business process.

  1. Optimize customer service – Before your customer finds any error in your service/product you proactively acting on error and fixing those error. This will help to build relationship with customer.
  2. Increase sales – With help of IOT and CRM system you are finding untouched opportunity and using those opportunity to increase your sale.
  3. Personalize customer experience – You are analyzing data provided by IOT and CRM system and building user based predictive model to enable personalize experience to user.
  4. Customer retention – CRM provide customer data and relationship. IOT data providing customer behavior. This will help any business to personalize and target marketing for their customer.
  5. Omnichannel instore experience – IOT and CRM is helping business to enable 360 omnichannel customer experience. This process will help and suggest the products which the customer might purchase.

APIs  integration with IOT and CRM helping business to enable higher degree of personalization, target marketing, optimize price model, higher revenue and enhance customer satisfaction.

Anypoint Platform: External (OKTA) Identity Management

Anypoint Platform acts as a client provider by default, but you can also configure external client providers to authorize client applications. As an API owner, you can apply an OAuth 2.0 policy to authorize client applications that try to access your API. You need an OAuth 2.0 provider to use an OAuth 2.0 policy. You can configure more than one client provider and associate the client providers with different environments. If you configure multiple client providers after you have already created environments, you can associate the new client providers with the environment. 

MuleSoft supports client management by identity providers that implement the OpenID Connect Dynamic Client Registration open standard. MuleSoft explicitly verifies support in Anypoint Platform for Salesforce, Okta, and OpenAM v14 Dynamic Client Registration. The following table contains examples of the URLs you need to supply, depending on your provider, during registration.

URL NameOkta Example URLOpenAM Example URLSalesforce Example URL
Base https://example.okta.com/oauth2/v1 https://example.com/openam/oauth2 https://example.salesforce.com/services/oauth2
Client Registration {BASE URL}/clients {BASE URL}/connect/register {BASE URL}/register
Authorize {BASE URL}/authorize {BASE URL}/authorize {BASE URL}/authorize
Token {BASE URL}/token {BASE URL}/access_token {BASE URL}/token
Token Introspection {BASE URL}/introspect {BASE URL}/introspect {BASE URL}/introspect
URL Name Okta Example URL OpenAM Example URL Salesforce Example URL

Steps to Create External Client Provider

  • Log in to Anypoint Platform using an account that has the organization administrator role.
  • In Anypoint Platform, click Access Management.
  • In the menu on the left, click Client Providers.

  • Click Add Client Provider, and then select OpenID Connect Dynamic Client Registration.
    The Add OIDC client provider page appears.
  • After obtaining values from your identity provider’s configuration, complete the following required fields in each section:
    • Dynamic Client Registration
      • Issuer: URL that the OpenID provider asserts is its trusted issuer.
      • Client Registration URL: The URL to dynamically register client applications as a client application for your identity provider.
      • Authorization Header
        • For Okta, this value is SSWS ${api_token}, where api_token is an API token created through Okta.
        • For ForgeRock, this value is Bearer ${api_token}, where api_token is an API token created through ForgeRock.
        • For Salesforce, this value is Bearer ${api_token}, where api_token is an API token created through Salesforce. In Advanced Settings you can also select:
      • Disable server certificate validation: Disables server certificate validation if your OpenID client management instance presents a self-signed certificate, or one signed by an internal certificate authority.
      • Enable client deletion in Anypoint Platform: Enables deletion of clients created with this integration.
      • Enable client deletion and updates in IdP: To use this option, you must also select the Enable client deletion in Anypoint Platform option.
    • Token Introspection Client
      • Client ID: The client ID for an existing client in your IdP capable of introspection of all tokens from all clients.
        • For Okta, this value should be a “Confidential” client.
        • For ForgeRock, this value should be a “Confidential” client.
        • For Salesforce, this value should be a “Confidential” client.
      • Client Secret: The client secret that corresponds to the client ID.
    • OpenID Connect Authorization URLs
      • Authorize URL: The URL where the user authenticates and grants OpenID Connect client applications access to the user’s identity.
      • Token URL: The URL that provides the user’s identity, encoded in a secure JSON Web Token.
      • Token Introspection URL: endpoint that returns metadata about the access token, including expiration and token active state.

Mule 4: Consume a SOAP Webservice

The Web Service Consumer is an existing connector in Mule 4 that you can configure to point to a SOAP based web service. Webservice consumer call webservice hosted elsewhere as WSDL SOAP services and get response. This connector simplified process and encapsulated all the feature to consume SOAP based webservice. When no connector is available specific to any product (like Service-Now, Workday etc.), which is hosted as SOAP based webservice then this webservice consumer Connector enables any services to consume.

The main feature of this connector is

  • Consuming DOC Literal Web services.
  • SOAP multipart messages.
  • SOAP Headers.
  • DataSense support for SOAP Headers, SOAP Body, and Attachment.
  • Embedded DataWeave transformations inside the operation.
  • Support and Unified experience for SOAP with attachments and MTOM handling.
  • Custom HTTP configuration as transport (runtime and design time).
  • Web Service Security (WS Security) support.

Connector Configuration- In this section we define connector configuration to communicate with SOAP based webservice end point. By default, connector uses a simple non protected HTTP configuration to send all outgoing SOAP message.  In connector configuration you can select your SOAP version from drop down  and provide WSDL location. Connector extract and populates Service, Port and webservice endpoint address from WSDL file.

But if you are using secure endpoint address with HTTPS you need to configure custom Transportation Configuration for HTTPS.

These are the steps to enable your secure HTTPS endpoint.

  • Create jks file with keytool command
 keytool -keystore clientkeystore.jks -genkey -alias client 
  • Download certificate from WSDL HTTPS endpoint and add this certificate in your JKS file with below command
keytool -importcert -file certificate.cer -keystore clientkeystore.jks -alias "Alias"
  • Now configure TLS Context for Webservice consumer connector.
<tls:context name="TLS_Context" doc:name="TLS Context" doc:id="f634b824-2695-4d5f-8789-7a309b1511cb" >
           <tls:trust-store path="certificate/clientkeystore.jks" password="xxxxxx" type="jks" />
     </tls:context>
  • Now configure HTTP Request configuration for HTTPS endpoint.
<http:request-config name="HTTPS_Request_configuration" doc:name="HTTPS Request configuration" doc:id="02db1fd9-9f04-4eae-83cf-df43effd25d2">
           <http:request-connection protocol="HTTPS" host="service.vanrish.com" port="443" tlsContext="TLS_Context">
     	   </http:request-connection>
	</http:request-config>

  • If TLS and HTTPS configuration configured then you can select HTTP request configuration from Webservice consumer
<wsc:config name="BookService_Web_Service_Consumer_Config" doc:name="Book Web Service Consumer Config" doc:id="59fd0d73-f90d-4cf0-9855-c008307067a2" >
 <wsc:connection wsdlLocation="wsdl\bookservice.wsdl" service="BookService" port="BookServicePort" address="https://service.vanrish.com:443/service/BookService">
  <wsc:custom-transport-configuration >
    <wsc:http-transport-configuration requesterConfig="HTTPS_Request_configuration"/>
  </wsc:custom-transport-configuration>
 </wsc:connection>
</wsc:config>

Connector Parameter- If connector configuration is configured properly, your operation parameters are available from WSDL as drop down options.

In Message section there are three parameters available

  1. Body – The Body is main part of the SOAP message. The body element accepts embedded DataWeave scripts as values so that you can construct the XML request without having a side effect on the message or having to use multiple components to create the request.
  2. Headers – The headers element contains application-specific information (like authentication, payment, and so on) about the SOAP message . This elements accepts embedded DataWeave scripts as values.
  3. Attachment – The attachments element enables you to bind attachments to the SOAP message. This element also accepts embedded DataWeave scripts as values.

Since you configured custom HTTPS connector for your webservice consumer Connector you can configure Transport Configuration. In Transport header section you can select “Edit inline” and add all your header parameters in line

<wsc:consume doc:name="Consume" doc:id="ca5a1247-7cf6-4c7f-a442-b6fd037c13c9" config-ref="BookService_Web_Service_Consumer_Config" operation="AddBook">
       <wsc:transport-headers >
          <wsc:transport-header key="SOAPAction" value="AddBook" />
          <wsc:transport-header key="Content-Type" value="text/xml; charset=UTF-8" />
          <wsc:transport-header key="Authorization" value="${book.authorization}" />
       </wsc:transport-headers>
 </wsc:consume>

Here is webservice consumer flow diagram

Code for this flow

<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
	xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns:tls="http://www.mulesoft.org/schema/mule/tls"
	xmlns:wsc="http://www.mulesoft.org/schema/mule/wsc"
	xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/ee/core http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/wsc http://www.mulesoft.org/schema/mule/wsc/current/mule-wsc.xsd
http://www.mulesoft.org/schema/mule/tls http://www.mulesoft.org/schema/mule/tls/current/mule-tls.xsd
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd">
	
	<wsc:config name="BookService_Web_Service_Consumer_Config" doc:name="Book Web Service Consumer Config" doc:id="59fd0d73-f90d-4cf0-9855-c008307067a2" >
            <wsc:connection wsdlLocation="wsdl\bookservice.wsdl" service="BookService" port="BookServicePort" address="https://service.vanrish.com:443/service/BookService">
	            <wsc:custom-transport-configuration >
					<wsc:http-transport-configuration requesterConfig="HTTPS_Request_configuration" />
				</wsc:custom-transport-configuration>
            </wsc:connection>
     </wsc:config>

	<tls:context name="TLS_Context" doc:name="TLS Context" doc:id="f634b824-2695-4d5f-8789-7a309b1511cb" >
           <tls:trust-store path="certificate/clientkeystore.jks" password="changeit" type="jks" />
     </tls:context>

    <http:request-config name="HTTPS_Request_configuration" doc:name="HTTPS Request configuration" doc:id="02db1fd9-9f04-4eae-83cf-df43effd25d2">
           <http:request-connection protocol="HTTPS" host="service.vanrish.com" port="443" tlsContext="TLS_Context">
     	   </http:request-connection>
	</http:request-config>

	<sub-flow name="addbook-ServiceSub_Flow" doc:id="511f0969-0b7d-4b7e-a113-60ef03e97648" >
             <logger level="INFO" doc:name="Logger" doc:id="e6bd0106-e512-4fdd-97cf-1dbd77e1e0e7" message="Entering into AddBook flow"/>
                             <ee:transform doc:name="Transform Message" doc:id="06cc17de-86a9-4c53-a2f4-167d9561bed9" >
                                           <ee:message >
                                                          <ee:set-payload ><![CDATA[%dw 2.0
 output application/xml skipNullOn="everywhere"
 ns n0  https://www.service.vanrish.com/BookService/
  ---
   n0#AddBook:
         {
                 n0#Book : {
                 	ID: payload.id,
                 	Title : payload.title,
                 	Author : payload.author
                 }
         }]]></ee:set-payload>
                                           </ee:message>
                             </ee:transform>
                             <logger level="INFO" doc:name="Logger" doc:id="ce84f628-7b38-4d2d-b5e3-9fdded2c9289" message="soap request --> #[payload]"/>
                             
<wsc:consume doc:name="Consume" doc:id="ca5a1247-7cf6-4c7f-a442-b6fd037c13c9" config-ref="BookService_Web_Service_Consumer_Config" operation="AddBook">
                                           <wsc:transport-headers >
                                                          <wsc:transport-header key="SOAPAction" value="AddBook" />
                                                          <wsc:transport-header key="Content-Type" value="text/xml; charset=UTF-8" />
                                                          <wsc:transport-header key="Authorization" value="${book.authorization}" />
                                           </wsc:transport-headers>
                             </wsc:consume>
                             <logger level="INFO" doc:name="Logger" doc:id="680d69e0-2b01-480c-afe7-660ca22b2f9f" message="AddBook Output-->#[payload]"/>
                             <ee:transform doc:name="Transform Message" doc:id="72d26561-107a-4c6e-a7d4-85bd18e0d316" >
                                           <ee:message >
                                                          <ee:set-payload ><![CDATA[%dw 2.0
ns ns0 https://www.service.vanrish.com/BookService/
 

output application/json skipNullOn="everywhere"
---
payload.body.ns0#AddBookResponse]]></ee:set-payload>
                                           </ee:message>
                             </ee:transform>
                             <logger level="INFO" doc:name="Logger" doc:id="ea517185-efa4-4bf2-a03f-e8bd4d308e80" message="Output AddBook --> #[payload]"/>
              </sub-flow>
</mule>

Mulesoft: FedRamp Compliance Cloud Integration for Government

Fiscal year 2019, government estimated $45.8 billion on IT investments at major civilian agencies, which will be used to acquire, develop, and implement modern technologies.78% of this budget goes to maintain existing IT system. In a constantly changing IT landscape, the migration of federal on-premise technologies to the cloud is increasing every year. Federal agencies have the opportunity to save money and time by adopting innovative cloud services to meet their critical mission needs and keep up to date with current technology. Federal agencies are required by law to protect any federal information that is collected, maintained, processed, disseminated, or disposed of by cloud service offerings, in accordance with FedRAMP requirements.

What is Federal Risk and Authorization Management Program (FedRamp) ? 

FedRamp is a US government-wide program that delivers a standard approach to security assessment, authorization, and continuous monitoring for cloud products and services. The stakeholders for FedRamps are 

  1. Federal Agencies
  2. FedRamp PMO & JAB(Joint Authorization Board)
  3. Third Party Assessment Organization

FedRamp Process There are 3 ways a cloud service can be proposed for FedRamp Authorization.

  1. Cloud BPA — Cloud Services through FCCI BPAs
  2. Government Cloud Systems — Services must be intended for use by multiple government or government approved agencies.
  3. Agency Sponsorship — This is the most popular route for cloud service providers (CSPs) to take when working toward a FedRAMP Authorization. CSP to establish a partnership with an Agency and agree to work together for an Authority to Operate(ATO).

Mulesoft FedRAMP Authorize Integration Platform

Mulesoft recently announced, FedRAMP process implementation of Anypoint Platform. MuleSoft is one of the first integration platform companies with FedRamp authorization and enabling both on-premises and cloud integration in the federal government and state government. Enablement of FedRamp of Mulesoft Anypoint platform, government IT teams can leverage the same core Anypoint Platform benefits in the cloud to accelerate their project delivery via reusable APIs.Anypoint Platform allows all government integration assets to be managed and monitored from a single, secure, cloud based management console, simplifying operations and increasing IT agility. 

Mulesoft Anypoint platform enables FedRamp-compliant iPAAS for government organization. Government IT integration project deploy in Anypoint platform within Mulesoft Government cloud 

  1. Accelerate government IT project deliveries by deploying sophisticated cross-cloud integration applications and create new APIs on top of existing data sources
  2. Project deliveries improve efficiencies at lower cost by allowing IT integration teams to focus on designing, deploying, and managing integrations in the cloud and allowing agencies to only pay for what they use, .
  3. Reduce risk of your IT project integration and increase application reliability by using of self-healing mechanism to recover from problems and load balancing.  

What is Mulesoft Government Cloud?

Mulesoft government cloud is a FedRamp-compliant, cloud based deployment environment for Anypoint platform. 

  1. It is built on AWS GovCloud with FedRamp control. 
  2. Mule Runtimes configured in secure mode to support the highest encryption standards and FIPS(Federal Information Processing Standard)  140-2 hardware and software encryption compliance.
  3. It is FedRamp-compliance at the moderate impact level.
  4. It is continuous 3rd party(3 POs) auditing and monitoring of security control.

Mulesoft government cloud can be access through this link https://gov.anypoint.mulesoft.com/login/ . Mulesoft Government cloud resources are available through Anypoint exchange. Mulesoft Government cloud exchange URL is https://gov.anypoint.mulesoft.com/exchange/ .

If you are accessing FedRamp-compliant Anypoint platform, after logging you get end user agreement as a consent. It is very typical for FedRamp-compliant government application.  

Conclusion — Executing any government or state project and working on different integration as well as API enablement, FedRamp-compliant Anypoint platform is one of the best options. It accelerate IT project deliveries, improve efficiencies and reduce IT risk .    

Mule 4: APIKit for SOAP Webservice

Mule 4 introduced APIKit for soap webservice. It is very similar to APIKit for Rest. In SOAP APIKit, it accepts WSDL file instead of RAML file. APIKit for SOAP generates work flow from remote WSDL file or downloaded WSDL file in your system.

To create SOAP APIKit project, First create Mulesoft project with these steps in Anypoint studio.

Under File Menu -> select New -> Mule Project

Mule 4 Project Settings

In above pic WSDL file gets selected from local folder to create Mule Project.

Once you click finish, it generates default APIKit flow based on WSDL file.

In this Mulesoft SOAP APIKit example project, application is consuming SOAP webservice and exposing WSDL and enabling SOAP webservice.

Mule 4 API Kit for Soap Router

In SOAP Router APIKit, APIKit SOAP Configuration is defined WSDL location, Services and Port from WSDL file.

API Kit SOAP configuration

In above configuration, “soapkit-config” SOAP Router look up for requested method. Based on requested method it reroutes request from api-main flow to method flow. In this example, requested method is “ExecuteTransaction” from existing wsdl, so method flow name is

<flow name=“ExecuteTransaction:\soapkit-config”>  

In this example we are consuming same WSDL but end point is different.

To call same WSDL we have to format our request based on WSDL file. In dataweave, create request based on WSDL and sending request through HTTP connector.

Here is dataweave transformation to generate request for existing WSDL file

%dw 2.0
output application/xml
ns soap http://schemas.xmlsoap.org/soap/envelope/
ns xsi http://www.w3.org/2001/XMLSchema-instance
ns ns0 http://localhost/Intellect/ExternalWebService
ns xsd http://www.w3.org/2001/XMLSchema
ns ns1 xsd:string
---
 
{
  	soap#Envelope @('xmlns:xsi': 'http://www.w3.org/2001/XMLSchema-instance'): {
  	 	
  	soap#Body: {
     	ExecuteTransaction @('xmlns': 'http://localhost/Intellect/ExternalWebService'): {
     	  Request @(xsi#'type': 'xsd:string'): payload.soap#Body.ns0#ExecuteTransaction.Request 
     	 
     	  }
     	
    	}
    	
  	}
}

Here is main flow

Main flow for API SOAP Kit

Here is full code

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<mule xmlns="http://www.mulesoft.org/schema/mule/core"
xmlns:apikit-soap="http://www.mulesoft.org/schema/mule/apikit-soap"
xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
xmlns:http="http://www.mulesoft.org/schema/mule/http"
xmlns:wsc="http://www.mulesoft.org/schema/mule/wsc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.mulesoft.org/schema/mule/core
http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/http
http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
http://www.mulesoft.org/schema/mule/apikit-soap
http://www.mulesoft.org/schema/mule/apikit-soap/current/mule-apikit-soap.xsd
http://www.mulesoft.org/schema/mule/wsc
http://www.mulesoft.org/schema/mule/wsc/current/mule-wsc.xsd
http://www.mulesoft.org/schema/mule/ee/core
http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd"
> <http:listener-config basePath="/fda" name="api-httpListenerConfig"> <http:listener-connection host="0.0.0.0" port="8081"/> </http:listener-config> <apikit-soap:config httpStatusVarName="httpStatus" name="soapkit-config" port="ISTCS2SubmitOrderSoap" service="ISTCS2SubmitOrder" wsdlLocation="ISTCOrder.wsdl"/> <wsc:config doc:id="b2979182-c4e9-489b-9420-b9320cfe9311" doc:name="Web Service Consumer Config" name="Web_Service_Consumer_Config"> <wsc:connection address="https://enterprisetest.vanrish.com/pub/xchange/request/atlas" port="ISTCS2SubmitOrderSoap" service="ISTCS2SubmitOrder" wsdlLocation="api/ISTCOrder.wsdl"/> </wsc:config> <http:request-config doc:id="408de2f8-c21a-42af-bfe7-2d7e25d153b0" doc:name="HTTP Request configuration" name="HTTP_Request_configuration"> <http:request-connection host="enterprisetest.fadv.com" port="443" protocol="HTTPS"/> </http:request-config> <flow name="api-main"> <http:listener config-ref="api-httpListenerConfig" path="/ISTCS2SubmitOrder/ISTCS2SubmitOrderSoap"> <http:response statusCode="#[attributes.protocolHeaders.httpStatus default 200]"/> <http:error-response statusCode="#[attributes.protocolHeaders.httpStatus default 500]"> <http:body><![CDATA[#[payload]]]></http:body> </http:error-response> </http:listener> <apikit-soap:router config-ref="soapkit-config"> <apikit-soap:attributes><![CDATA[#[%dw 2.0 output application/java --- { headers: attributes.headers, method: attributes.method, queryString: attributes.queryString }]]]></apikit-soap:attributes> </apikit-soap:router> </flow> <flow name="ExecuteTransaction:\soapkit-config"> <logger doc:id="62a3748e-b81c-4a95-9af0-99c5a282b237" doc:name="Logger" level="INFO" message="Entering into flow"/> <ee:transform doc:id="c130d7ff-bd70-4af0-b7d4-9a6caa0d771f"> <ee:message> <ee:set-payload><![CDATA[%dw 2.0 output application/xml ns soap http://schemas.xmlsoap.org/soap/envelope/ ns xsi http://www.w3.org/2001/XMLSchema-instance ns ns0 http://localhost/Intellect/ExternalWebService ns xsd http://www.w3.org/2001/XMLSchema ns ns1 xsd:string --- { soap#Envelope @('xmlns:xsi': 'http://www.w3.org/2001/XMLSchema-instance'): { soap#Body: { ExecuteTransaction @('xmlns': 'http://localhost/Intellect/ExternalWebService'): { Request @(xsi#'type': 'xsd:string'): payload.soap#Body.ns0#ExecuteTransaction.Request } } } } ]]></ee:set-payload> </ee:message> </ee:transform> <http:request config-ref="HTTP_Request_configuration" doc:id="6d7001f3-b90a-4ed8-96d2-d577329d21d5" doc:name="Request" method="POST" path="/pub/xchange/request/atlas"/> <logger doc:id="a05e704f-e539-48f3-9556-fe66641e3f64" doc:name="Logger" level="INFO" message="#[payload]"/> </flow> </mule>


Mule 4: Ease Your Integration Challenges

Much awaited Mulesoft 4 was officially announced in Mulesoft Connect 2018 in San Jose. When Mulesoft was born, it was really to create software that helps to interact systems or source of information quickly within or outside company. So the speed is an incredibly important thing over the years to develop and interact within systems. Need of speed for application and development hasn’t change drastically over the years but needs and requirement of customer’s application have changed. The integration landscape has also magnified. There are hundreds of new systems and sources of information to connect to, with more and more integration requirements. This integration landscape gets very messy and very quickly.

            Mule 4 provides a simplified language, simplified runtime engine and ultimately reduces management complexity.  It helps customers, developers to deliver application faster. Mule4 is really radically simplified development. It is providing new tool to simplify your development, deployment and management of your integration/API. It is also providing a platform to reuse Mule component without affecting existing application for faster development. Mule 4 is evolution of Mule3. You will not seem lost in Mule 4, if you are coming from Mule3. But Mule 4 implements fewer concepts and steps to simplify whole development/integration process. Mule 4 has now java skill is optional. In this release Mulesoft is improving tool and making error reporting more robust and platform independent.

Now let’s go one by one with all these new Mule4 features.

1. Simplified Event Processing and Messaging — Mule event is immutable, so every change to an instance of a Mule event results in the creation of a new instance. It contains the core information processed by the runtime. It travels through components inside your Mule app following the configured application logic. A Mule event is generated when a trigger (such as an HTTP request or a change to a database or file) reaches the Event source of a flow. This trigger could be an external event triggered by a resource that might be external to the Mule app.

Mule 4 Event flow

2. New Event and Message structure — Mule 4 includes a simplified Mule message model in which each Mule event has a message and variables associated with it. A Mule message is composed of a payload and its attributes (metadata, such as file size). Variables hold arbitrary user information such as operation results, auxiliary values, and so on.

Mule 4 message

Mules 4 do not have Inbound, Outbound and Attachment properties like  Mule 3. In mule 4 all information are saved in variables and attributes. Attributes in Mule 4 replace inbound properties. Attributes can be easily accessed through expressions.

 These are advantages to use Attributes in Mule 4.

  • They are strongly typed, so you can easily see what data is available.
  • They can easily be stored in variables that you can access throughout your flow
Example :
#[attributes.uriParams.jobnumber]

Outbound properties — Mule 4 has no concept for outbound properties like in Mule 3. So you can set status code response or header information in Mule 4 through Dataweave expression without introducing any side effects in the main flow.

Example:

 
<ee:transform xsi:schemaLocation="http://www.mulesoft.org/schema/mule/ee/core
 http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd">
       <ee:message>
         <ee:set-payload>
           <![CDATA[
                %dw 2.0
                output application/json
                 ---
                 {message: "Bad request"}]]>
           </ee:set-payload>
         </ee:message>
    <ee:variables>
       <ee:set-variable variableName="httpStatus">400</ee:set-variable>
    </ee:variables>
  </ee:transform>

Session Properties –In Mule 4 Session properties are no longer exist. Data store in variables are passes along with  different flow.

3. Seamless data access & streaming – Mule 4 has fewer concepts and steps. Now every steps and task of  java language knowledge is optional. Mule 4 is not only leveraging DataWeave as a transformation language, but expression language as well. For example in Mule 3  XML/CSV data need to be converted into java object to parse or reroute them. Mule 4 gives the ability to parse or reroute through Dataweave expression without converting into java. These steps simplify your implementation without using java.

Mule 4 Data Access

4. Dataweave 2.0 — Mule 4 introduces DataWeave as the default expression language replacing Mule Expression Language (MEL) with a scripting and transformation engine. It is combined with the built-in streaming capabilities; this change simplifies many common tasks. Mule 4 simplifies data iteration. DataWeave knows how to iterate a json array. You don’t even need to specify it is json. No need to use <json:json-to-object-transformer /> to convert data into java object.

Mule 4 vs Mule 3 flow comparison

Here are few points about Dataweave 2.0

  • Simpler syntax to learn
  • Human readable descriptions of all data types
  • Applies complex routing/filter rules.
  • Easy access to payload data without the need for transformation.
  • Performs any kind of data transformation, normalization, grouping, joins, pivoting and filtering.

5. Repeatable Streaming – Mule 4 introduces repeatable streams as its default framework for handling streams. To understand the changes introduced in Mule 4, it is necessary to understand how Mule3 data streams are consumed

Mule 3 data streaming examples

In above three different Mule 3 flows, once stream data is consumed by one node it is empty stream for 2nd node. So in the above first example, in order to log the stream payload , the logger has to consume the entire stream of data from HTTP connector. This means that the full content will be loaded into memory. So if the content is too big and you’re loading into memory, there is a good chance the application might run out of memory.

So Mule 4 repeatable streams enable you to

  • Read a stream more than once
  • Have concurrent access to the stream.
  • Random Access
  • Streams of bytes or streams of objects

As a component consumes the stream, Mule saves its content into a temporary buffer. The runtime then feeds the component from the temporary buffer, ensuring that each component receives the full stream, regardless of how much of the stream was already consumed by any prior component

Here are few points, how repeatable streams works in Mule 4

  • Payload is read into memory as it is consumed
  • If payload stream buffer size is > 512K (default) then it will be persisted to disk.
  • Payload stream buffer size can be increased or decreased by configuration to optimize performance
  • Any stream can be read at any random position, by any random thread concurrently

6. Error Handling — In Mule 4 error handling has been changed significantly. Now In mule 4 you can discover errors at design time with visual interface. You no need to deal with java exception directly and it is easy to discover error while you are building flow. Every flow listed all possible exception which potential arises during execution.

Mule 4 Error Handling

Now errors that occur in Mule fall into two categories

  • Messaging errors
  • System errors

  Messaging errors — Mule throws a messaging error (a Mule error) whenever a problem occurs within a flow. To handle Mule errors, you can set up On Error components inside the scope-like Error Handler component. By default, any unhandled errors are logged and propagated.

System errors — Mule throws a system error when an exception occurs at the system level . If no Mule Event is involved, the errors are handled by a system error handler.

Try catch Scope — Mule 4 introduces a new try scope that you can use within a flow to do error handling of just inner components/connectors. This try scope also supports transactions and in this way it is replacing Old Mule 3 transaction scope.

Mule 4 A new try catch block

7. Class Loader Isolation — Class loader separates application completely from Mule runtime and connector runtime. So, library file changes (jar version) do not affect your application. This  also gives flexibility to your application to run any Spring version without worry about Mulesoft spring version. Connectors are distributed outside the runtime as well, making it possible to get connector enhancements and fixes without having to upgrade the runtime or vice versa

In above pic showing that every component in any application have their own class loader and running independently on own class loader.

8. Runtime Engine — Mule 4 engine is new reactive and non-blocking engine. In Mule 4 non-blocking flow always on, so no processing strategy in flow. One best feature of Mule 4 engine is, It is self-tuning runtime engine. So what does this mean? If Mule 4 engine is processing your applications on 3 different thread pools, So runtime knows  which application should be executed by each thread pool. So operation put in corresponding thread pool based on high intensive CPU processing or light intensive CPU processing or I/O operation. Then 3 pools are dynamic resizing automatically to execute application through self-tuning.


Mule 4 : Self tuning run time engine

So now self-tuning creates custom thread pools based on specific tasks. Mule 4 engine makes it possible to achieve optimal performance without having to do manual tuning steps.

Conclusion

Overall Mule 4 is trying to make application development easy, fast and robust. There are more features included in Mule 4 which I will try to cover in my next blog. I will also try to cover more in depth info in above topic of Mule 4. Please keep tuning for my next blog.