Preview

(:smile_cat: - checked by mulint)

• The code has been checked into GitHub, into the correct feature branch (standard PR process).
• A GitHub Pull Request is made to have the API reviewed.
• Run the current release of mulint and review any warnings or errors.
• 😸 API Kit HTTP Listeners should not be listening on the default generated uri. They should follow the RAML specification
  • Default is /api/* and /console/*
  • Should be something like /api/wstrl/v1/* and /console/api/wstrl/v1/*
• 😸 Make sure that projects use a domain project if deploying on-prem and the http listener: standardHTTPS is being used and that any other http listener is removed from the project.
• 😸 If a cloud deployment, verify that the "https.port" property is used. CloudHub will replace those values on deployment. (If not applicable, check the box.)
• Verify that the maven version number for the artifact has been changed if this is not the first release.
• 😸 If a cloud deployment, in the org.mule.tools.maven plugin, verify that the anypoint.platform.client_id and anypoint.platform.client_secret are using placeholders.
• 😸 If a cloud deployment, verify there are no properties for anypoint.platform.client_id and anypoint.platform.client_secret. These are added by Team City and should never be stored in a project.
• 😸 Verify all "internal" http:request-config elements use tlsContext-ref="clientTlsContext"
  • Detailed information about it: https://ufginsurance.atlassian.net/wiki/spaces/IS/pages/75890708/Updating+Domain+project
• Verify that .project and .classpath files are not in GitHub (mulint does validate that .gitignore ignores them).
• 😸 Each flow in the interface definition should have a reference exception strategy. If using common-errors then it should be set to that.
• MUnit tests exist for as appropriate for API functionality.
• The API adhere to the security standards (including: TLS 1.2 is used for all communication. Both REST and SOAP integrations).
  • client_id and client_secret should be enabled for all experience apis, even in dev. With the latest upgrade to Anypoint we are able to promote policies through environments. So development should have ALL policies applied to them so we can easily promote and developers have tested things completely
• 😸 The project specifies the domain project that is used (if on-prem, domain projects are not supported for cloudhub).
• The API has been documented in Exchange.
  • The documentation should also list any dependencies they have on other APIs. (Ex: rollout-coordinator-process-api depends on wstrl-system-api, etc)
• The API is published in Exchange and API Manager has been configured for the API.
• The API has had all identified policies applied to it. - Done by C4E member
  • If this is an Experience API then the following policies should be applied:
    • Client ID enforcement
    • CORS Policy
  • If this is a Process or System API then the following policies should be applied (only for post and put):
    • JSON Threat Protection (If the inbound / outbound payloads are JSON) - json threat
    • XML Threat Protection (If the inbound / outbound payloads are XML) - xml threat
• 😸 If template project used verify that all configurations are correct. If template project was not used then this step will take time as all template project changes need to be applied to the api project manually
  • pom.xml has updated the groupId and version number. The "template" property has been removed
  • pom.xml is updated for Artifactory
  • Logging configuration
    • There should be no references to template name you used. Do a global search and replace in this file so your API name is used
  • CI / CD configuration for variable replacement
• 😸 No hard coded urls, ports, hosts, etc. These should all be externalized into property files if they are expected to change.
• We should only communicate over HTTPS unless there is a compelling reason (legacy service, etc.).
• Run a mvn clean package on the project from command line, verify all tests pass and there are no errors.
  • You may need to pass in arguments for mule.env and https.port (mvn clean package -Dmule.env=local -Dhttps.port=8443)
• Flows and flow components should be named accordingly so that it can be quickly determined what it is doing (Transform Message = bad, Transform SOAP Request, Create SOAP Request = good)
• 😸 Global configuration should be placed in "global.xml", there should not be any global configurations in the implementation files
• Dataweave has been placed in external files and not done inline.
• 😸 The API uses common-errors and the generated exception strategy is deleted from the api kit flow
• 😸 Use Parameterized Sql to avoid SQL injection
• 😸 The API is using api-gateway-1.0.x (version number can change and should change based on added functionality) in the pom.xml file and mule-project.xml (if on-prem, domain projects are not supported for cloudhub).
• 😸 No mule.env environment variable should be defined in mule-app.properties (this file is generated from editing mule-project.xml)
• It is highly suggested that the API use the common-dataweave project / jar for transformations.
• A Team City build configuration should be created for the API that is being reviewed.
• NO passwords should be put into source control. Use property placeholders. Check api.Local.properties in particular. (mulint does a cursory check)