Configure an ERP-like application

MDriven is a model-driven development framework in which UML-like models are the application’s central definition. The supplied documentation states that MDriven can generate databases, user interfaces, and APIs from the model, allowing developers to focus on business logic rather than repetitive boilerplate code.

An ERP-like or line-of-business application commonly has persistent business records, relationships between those records, business rules, user access requirements, and deployment requirements. The following outline describes how the documented MDriven capabilities can be applied to that kind of application.

1. Model the business domain

Create UML-like class diagrams for the application’s business entities. Define attributes, types, constraints, validation rules, inheritance, associations, and compositions as appropriate for the domain.

For example, an order-management domain might include business entities such as customers, orders, order lines, and products. The specific entities and relationships should be determined by the organization’s requirements.

The model is documented as the single source of truth. MDriven can transform the model into a normalized SQL database and generate application elements from it.

2. Define business rules and lifecycles

Use OCL (Object Constraint Language) for validation rules and derived expressions. The documentation also states that state machines can model complex behavior and object lifecycles.

For a business process with controlled stages, define the relevant lifecycle states and the conditions under which records may move between those states. Keep rules in the model so they can be applied consistently wherever the model is used.

3. Create task-focused ViewModels

Use ViewModels to shape domain-model data for specific use cases without changing the domain model. Expressions can be used to calculate derived values dynamically.

Examples of task-focused views may include:

• A view for finding and reviewing records.
• A view for editing a business document and its related records.
• A view for presenting calculated or summary information.

The exact screen, form, navigation, and action configuration should be confirmed against the applicable ViewModel and Turnkey documentation before publication.

4. Configure access and workflows

The documentation states that role-based access control can be defined in the model. Define application roles and use those roles to control access according to the organization’s responsibilities and security requirements.

The source also describes transactional workflows with ACID compliance and built-in audit logging. Confirm the detailed configuration requirements for transactions, auditing, and data-access restrictions in the relevant product documentation before prescribing implementation steps.

5. Configure persistence

MDriven documentation states that the framework generates a normalized SQL database from the model and supports schema evolution when the model changes. It lists SQL Server, PostgreSQL, Oracle, and other major databases as supported database options.

Before production use, select a database platform and establish a process for managing model changes, database changes, credentials, backups, and production validation.

6. Select a deployment approach

The Deployment documentation describes deployment resources for:

• On-premises and cloud deployments.
• Windows IIS.
• Microsoft Azure.
• Docker containers.
• Linux deployments using Nginx or Apache.
• macOS deployments using Apache.
• CI/CD workflows.
• Scaling and load-balancing considerations.

Turnkey documentation also includes deployment and scaling resources, including Azure deployment, scaling Turnkey on Azure, and load-balancing considerations.

Choose a deployment approach that matches the application’s operating environment, security requirements, database choice, expected load, and operational support model.

7. Plan integrations

The MDriven developer guide states that external services can be connected through REST API integrations and that functionality can be extended with modular add-ons. Identify the business records and processes that each integration serves before implementing it, and keep external data aligned with the domain model.

Configuration review checklist

Before production deployment, verify that:

• The domain model represents the required business entities, attributes, and relationships.
• Validation rules and lifecycle behavior are defined where needed.
• ViewModels support the intended user tasks without altering the domain model.
• Role-based access requirements have been defined and reviewed.
• The selected database and schema-evolution process have been tested.
• The deployment approach has been selected from the supported deployment options.
• Integration boundaries and data mappings are documented.
• Scaling, load balancing, monitoring, and operational requirements have been assessed.

Needs human review

The following details appeared in the draft but are not supported by the supplied source passages and should be verified against their cited detailed pages before being included:

• Specific documentation-page links for Designer, associations, unique constraints, OCL, state machines, ViewModels, access control, data restrictions, MDrivenServer, and integrations.
• The claim that Turnkey has exactly three form types named seek, document, and report, including their stated behavior.
• Instructions for seek-and-pick selection, action contexts, and confirmation-action enablement.
• Claims about specific MDrivenServer features such as server-wide variables, server-side jobs, database download/upload, and a particular server interface path.
• References to MDrivenServerOverride.xml, HardServerUrl.xml, TurnkeySettingsOverride.xml, CommandLineOverride.xml, the pathtoapp setting, and the Nginx server_name procedure.
• The statement that a particular order lifecycle should include draft and confirmed states. This is a plausible example, but it is not documented in the supplied sources.