Date reviewed :

Reviewer name :
Mule Project Name:
Application version :
Eversana GitHub Location / Branch:
CloudHub Application Name:
Proposed/Actual region :
Proposed/Actual vCore allocation :
Proposed/Actual Business Group (ie: Integration, Share
Application owner :
Application developer :
Location of design artifacts :
Location of NFRs including :
Eversana Exchange/Asset Reference (URL):
Expected/Actual go-live date :
Type of service :
Connectors Used: (ie: WS, SAP, SFDC, DB, AZURE, etc)
Reviewer Comments:
All items that Require IMMEDIATE ATTENTION MUST be rectified for approval immediately.

Project StructureProject Design Naming ConventionProject Logging Error & exception handlin Project SecurityProject TestingProject NFR Project Implementation
Meets Expectaions 0 0 0 0 0 0 0 0 0
Mostly Meets Expectations 0 0 0 0 0 0 0 0 0
Partially Meets Expectations 0 0 0 0 0 0 0 0 0
Does Not Meet Expectations 0 0 0 0 0 0 0 0 0
Immediate Attention Required 0 0 0 0 0 0 0 0 0
Not Applicable 0 0 0 0 0 0 0 0 0
Not Reviewed 0 0 0 0 0 0 0 0 0

I. Project Structure
Does the project respects the standard project structure ?

Rule description Score Reference Comments

Follow project naming convention. Refer to Eversana - Mule Code Style Guide and Best Practices.docx
src/test folders should contain files related to testing
The git repository is cleaned of any trash files (files commited previously of the addition of a .gitignore file)
The project has been mavenized
The project pom is clean of any mulesoft repository, distributionManagement and groupId tags
The project name is the same than the repo GIT
add the finalName <finalName>${project.artifactId}</finalName> below the build tag
a REST project contains a RAML 1.0 file
a REST project includes a git submodule referencing the common-raml-library repository
a SOAP project contains wsdl, and schema in the src/main/wsdl folder
a SOAP project has its wsdl and schema present in the common-wsdl repository
a SOAP project has its wsdl properly versionned
schema and example files for metadata types, sample data for transformations
DW sample data is stored in src/test/resources
Transformations are saved in a DWL files.
DWL files are stored in src/main/resources/dataweave.
Properties are defined per environment
Package strcuture as defined in the Eversana - Mule Code Style Guide and Best Practices.docx
The
DWLproject contains
files are thesrc/main/resources.
stored in common .gitignore file

DWL files are stored in src/main/resources.

II. Naming Convention

INTERNAL
Does the development respects the naming convention as defined in :

Rule description Score Reference Comments

As a REST service, the URI follows the naming convention (Refer to Eversana - Mule Code Style Guide and Best Practices.docx)
As a SOAP service, the URI follows the naming convention
query parameters are camelCases
JSON properties are camelCase
XML elements and attributes names are camelCase
A consistency effort should be done when naming JSON property or XML element conveying a kind of information already defined elsewhere
Dataweave filename follows the naming convention
Each mulesoft component name appropriately. Avoid using default names for components. Uses descriptive names e.g. Choice name should be reflective of the decision. Loggers should describe what is being logged not
just Log.. Optionally identify private from sub-flows (ie: pf as private flow, cf as common flow, mf as main flow, sf as sub flow). API flow reference by api-impl.xml should follow the pattern {operation}-{function} (ie: get-
order-items)
Integration Name and applciation name follow standards
Logger should have meaningful name, not just Logger
API Naming conventions for RAML and associated artifacts should follow standardized naming conventions and structures.

III. Project Design

Rule description Score Reference Comments

global configurations are gathered in a x-global-config.xml file
by just looking at the content of the name-in configuration file, you should be able to grab each main step of the flow
API Resource are well indentified and are nouns
Operations respect semantic associated to HTTP verbs GET : retrieve, POST(*) : create, PUT : update,DELETE : delete… (*: POST can serve other use than creation)
HTTP response codes respect semantic associated to HTTP codes, 2XX, 3XX, 4XX (client errors), 5XX (server errors)
in a RAML file, types are gathered and defined as a root elements
REST and SOAP experience should provide an API Autodiscovery configuration
Does the code completely and correctly implement the design?
Common re-usable components are been used as per the project guidelines.
Project / Integration flow level in line documentation exists including - Use case , patterns etc.
Processes well defined / clear responsibilities
Design Patterns
Use of Dataweave
Custom dependencies defined on pom.xml must have comments
Reuse variable as possible. If variable store more information, before exiting the flow, make sure to Remove the variable. Use Remove Variable component
Listener port must used ${http.private.port} for HTTP and {https.private.port} for HTTPS

IV. Project Logging

Does the project conforms itself to logging guidelines?

Rule description Score Reference Comments

A mulesoft project must use the log4j2 configuration
Avoid debug statements for development and use debugger in Studio.
Limit logging of full payloads in Logger - consider Audit capability.
before each exception, a logger is present to trace the exception
Use correct Level - avoid INFO for errors and Debug statements.
Avoid using Logger aggressively throughout projects.
Avoid logging of messages in flows that utilize streaming.
Sufficient logging for traceability purposes
log an entry during the START, IN_PROGRESS, END, ERROR state of the transactions processing
alll logging code for debugging purposes must be set to DEBUG level

INTERNAL
V. Error & exception handling
Does the project conforms itself to error handling best practices?

Rule description Score Reference Comments

For REST service, the apikit exception strategy reference a "common-http-exception-handler" exception strategy
For REST service, flow exception strategy reference a "specific-exception-handler" exception strategy
Technical and business exception are handled as per requirement document
Global Exception Strategy defined to handle Technical Exceptions.
Relevant logic to validate and raise business exceptions.
Retries or Until Successful used before Technical Exception is raised. Set Until Successful to synchronous for Request-Reply APIs.
Returns json or xml payload with code, error type and error details to consumer.
Avoids failure of entire batch if a single error occurs unless requirement is to reject the entire batch. If failures are logged then please ensure a process is defined to support failed transactions.
Uses the Validator over Groovy to throw errors.
Sufficient Exception Strategies / Error Handling in place
Private flows have a defined Exception Strategy. When uing private flow, make sure to define or refer to an exception strategy
Notification raised for system errors requiring intervention or attention.
Notifications raised for business errors requiring intervention or attention.
Good use of HTTP status/error codes for APIs.
Error context is not lost if proxying to downstream services.
Error details provides required details to support resolution.
Error message provides clarity of date/time and severity of exceptions.
Library for error handling logic - Reuse the common error library
Error Handling - All errors must be captured and handled. System APIs returns the errors as it is to the Process/Experience API which will handle the error accordingly. Ex. sending an email notification or creating an incident o

VI. Project Security

Does the project conforms itself to security requirements?

Rule description Score Reference Comments

Valdiate hadling of secured data
HTTP communication must be made in secure mode
properties must be stored in a property file handled by a securePlaceHolder
Communication must be made in secure mode wherever possible
No client sensitive data must be logged or trace in custom business event
The communication is being secured with SSL? [One-way SSL, Two-way SSL]
Is sensitive data in .*-sec-{environment}.yaml files encrypted using the Mule Credentials Vault?
Uses triple DES or AES 256 for encryption? Has the secret been configured for each environment differently? Has the secure properties been used in mule-app.properties for CH apps?

When using the JDBC Connector avoid using Dynamic Queries as this is at risk of SQL Injection. Uses parameterized queries Use dynamic queries only if you don't have another choice, remember to validate the inputs
previously (using dynamic queries could cause SQL-Injection vulnerability https://www.owasp.org/index.php/SQL_Injection)
Connectors are configured to use basic authentication as a minimum but preferably 2Way SSL
Policy enforcement
Implements TLS 1.2+
all sensitive data such as user credentials must be secured

VII. Project Testing

Does the project conforms itself to testng standards?

Rule description Score Reference Comments

Test cases are given in directory /test/resources
Munits are in place and with coverage at least 90%
All the functional validation, technical failures should be covered in unit test cases
every flow/sub flow must have unit tests defined (both positive and -ve test cases). Separate Munit test suites for each flow
Create postman collections for each API

INTERNAL
PLEASE DON'T DELETE THIS TAB

Score
1 - Does Not Meet Expectations
2 - Partially Meets Expectations
3 - Mostly Meets Expectations
4 - Meets Expectations
-1 - Immediate Attention Required
0 - Not Reviewed
0 - Not Applicable

INTERNAL