Checklist
Use the following checklist to review the quality of a use-case implementation, covering the design (RAML), Mule Application implementation and Runtime configurations
Header
|
Key |
Value |
| Project Name | example-project-name |
| Application Name | example-app-name |
| Environment | sandbox | uat | prod |
| Owner | example-owner |
| Reviewer | example-reviewer |
| Date |
26 Jan 2018 |
RAML
|
Quality Attribute |
Item |
Yes/No |
Business Impact |
|---|---|---|---|
|
Conceptual |
Methods (GET,POST, PUT, DELETE) used properly |
|
High |
|
Maintainability |
Version defined (v1,1.0) for the resources |
|
Medium |
| Version, title and documentation defined |
|
Medium | |
| All fields camelCased |
|
Low | |
| RAML file name different from api.raml | Low | ||
|
Maintainability |
Schemas, Data Types, examples and traits defined |
|
High |
| Schemas, Data Types, examples and traits externalized |
|
High | |
| RAML fragments re-used |
|
High | |
|
Testability |
Examples/DataTypes contains valid – mocked data |
|
High |
| Error codes defined in each resource-method pair |
|
High | |
|
Security |
Security traits defined |
|
High |
| Confidential data obfuscated / avoided in examples, query parameters, etc |
|
High | |
|
Discoverability |
Schemas/Examples/DataTypes defined for each resource |
|
High |
|
Traceability |
TransactionID/callerID passed as a header parameter |
|
High |
Mule Application
|
Quality Attribute |
Item |
Yes/No |
Business Impact |
|---|---|---|---|
|
Conceptual |
Processes well defined / clear responsibilities |
|
High |
|
Maintainability |
Mavenized |
|
High |
| Expression/groovy scripts externalized |
|
Medium | |
| Properties per environment |
|
High | |
| Flows/Components Naming conventions |
|
Low | |
| Source code in Source Control System (GitHub/GitLab) |
|
High | |
|
Maintainability |
Flows Reuse |
|
High |
| Global elements defined |
|
High | |
| Implementation logic separated from the main XML (containing the APIKit router)
(preferably 1 XML per implementation unit) |
Medium | ||
| Dataweave Scripts externalized |
|
High | |
|
Maintainability |
Use of up to date components |
|
High |
|
Performance |
Use of Design Patterns |
|
High |
| Pool configurations defined (if using DB module) |
|
High | |
| Use of Dataweave for all transformations |
|
High | |
|
Testability |
MUnit tests defined |
|
High |
|
Security |
Use of HTTPS / SSL |
|
High |
|
Traceability |
Exception Strategies / Error Handling defined |
|
High |
|
Availability |
Reconnection Strategies defined (if any) |
|
High |
Anypoint Platform Configurations
|
Quality Attribute |
Item |
Yes/No |
Business Impact |
|---|---|---|---|
|
Maintainability |
API name properly defined (Design Center and Exchange) |
|
Medium |
| API version properly defined |
|
Medium | |
|
Scalability Performance |
Cloudhub vcores and workers assigned properly
(e.g: 0.1 dev. 1 prod) |
|
High |
|
Testability / Discoverability |
API Exchange Portal defined – private/public |
|
High |
|
Security / Traceability / Availability |
Permissions well identified and applied |
|
High |
| SLA tiers applied |
|
High | |
| Throttling policy applied |
|
High | |
|
Security |
Client ID enforcement policy applied |
|
High |
| Oauth 2.0 policy applied (if applies) |
|
High | |
|
Traceability |
API Active – Analytics working |
|
High |