Home

Developer Pre-review Checklist

(Assuming a PR was done)

• Run the current release of mulint and review any warnings or errors.
• Verify that .project and .classpath files are not in GitHub (mulint does validate that .gitignore ignores them).
• MUnit tests exist for as appropriate for API functionality.
• The API adhere to the naming standards that have been created.
• 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 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
• The API is using common types that have been defined and is not duplicating effort that has already been done.
• The mock server is turned on for the API.
• 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)
• 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.