You can use this page to choose the right MDriven integration approach when you connect a Turnkey application or MDrivenServer to browser features, collaboration tools, analytics, or deployment automation.
Choose an integration path
Start with the system or capability that you need to connect. An integration should have a clear owner, data boundary, authentication approach, and failure behavior before you implement it.
| If you need to... | Start here | Example |
|---|---|---|
| Use browser or device hardware from a Turnkey application | HowTos:Integrate Device Features in MDriven Apps Using the Navigator API | Use an EXT_Component (an AngularJS component) to request camera access through navigator.mediaDevices.getUserMedia and save the captured picture in the application.
|
| Notify a team when a shared development database changes | Documentation:MDrivenServer Slack web hook | Configure a Slack incoming-webhook URL on MDrivenServer so the channel receives a message when someone evolves the development system. This lets other developers update their code and rebuild before testing. |
| Add Google Analytics to a Turnkey application | HowTos:Google Analytics in Turnkey app | Put the supplied Analytics configuration files in the model's AssetsTK folder and set the analytics account value in the configuration.
|
| Automate model generation, build, upload, and database evolution | Documentation:ContinuousIntegration | Start Visual Studio with the solution and model automation arguments, provide the required MDrivenServer environment variables, and collect the produced automation log and package output. |
| Deploy or host an application | Documentation:Deployment | Choose the deployment guidance for IIS, Azure, Docker, Linux web servers, or CI/CD rather than treating deployment as an application API integration. |
Plan the boundary before you implement it
An integration boundary is the point at which your MDriven application exchanges data or behavior with another system. Define the boundary in the model and application design before adding configuration or custom code.
- Identify the direction of the exchange: does your application call the external system, receive a request, or both?
- Identify the data involved and the model objects that own it. For example, a camera integration creates or updates an application value only after the browser has granted camera permission.
- Decide how the external system authenticates and how credentials, tokens, or webhook URLs are stored and protected.
- Define what happens when the external system is unavailable, returns invalid data, or a user denies a browser permission.
- Test the integration in the target environment. Browser capabilities, network conditions, and deployment configuration can differ from local development.
Integration areas
Use the following areas to scope your work and locate the detailed guidance that applies to your implementation.
Authentication and access
Authentication establishes who is making a request; authorization determines what that authenticated identity may access. Common integration work includes OpenID Connect, OAuth 2, JSON Web Tokens (JWT), ASP.NET Identity, header-based authentication, single sign-on, Azure AD, and BankID.
For example, when an external identity provider authenticates a user, define how that identity maps to the application's access-control rules before allowing the user to see data. Model-level security and data-access design belong with the application model; see Documentation:Designer for the Designer documentation area.
External APIs and services
External service integration covers calls to and from REST, SOAP, and web APIs, as well as a single-page application (SPA) working with Turnkey. Establish the request and response contract first: required fields, response values, errors, and timeout behavior.
For example, when a service sends a customer identifier, validate that the identifier can be resolved to the intended model object before using it in business logic. Keep the external contract separate from the business rules represented in the model.
Data import and export
Data integration includes SQL Server imports, XML and JSON exchange, SQL imports that create associations, data convergence, and Excel-based exchange. Define a stable key for each imported record and decide whether an incoming row creates a new object, updates an existing object, or is rejected.
For example, when importing related rows, resolve the parent object before creating the association. Do not create an association based only on a display name that might not be unique.
Third-party and browser integrations
Third-party integrations can add payments, AI services, collaboration notifications, analytics, and device capabilities. The implementation must account for the third party's credentials, permissions, response format, and availability.
- For a collaboration notification triggered by database evolution, use Documentation:MDrivenServer Slack web hook. The webhook is configured in MDrivenServer, available from Turnkey at
<turnkeyurl>/__MDrivenServer. - For browser camera, location, network, media, vibration, Bluetooth, or battery capabilities, use HowTos:Integrate Device Features in MDriven Apps Using the Navigator API. Check that the browser supports the required Navigator API and handle the user's permission decision.
- For analytics configuration in a Turnkey app, use HowTos:Google Analytics in Turnkey app.
Keep integrations maintainable
Apply these practices to every integration:
- Keep business concepts and rules in the MDriven Designer model. Isolate technology-specific handling, such as browser JavaScript or webhook configuration, at the integration boundary.
- Validate incoming data before it changes model objects or associations.
- Do not rely on an external system being continuously available. Make failures visible to the appropriate user or operator and define whether the operation can be retried.
- Coordinate shared-environment changes. When a developer evolves a common development database, other developers using an older model can receive mismatch errors. Use the MDrivenServer Slack webhook to notify the team, then have developers merge the new code and rebuild before testing.
- Automate repeatable build, generation, upload, and evolution steps with continuous integration rather than relying on manual deployment steps.
- Review the deployment environment separately from the application integration. See Documentation:Deployment for hosting, server, and CI/CD deployment guidance.
See also
- Documentation:Designer
- Documentation:Framework
- Documentation:ContinuousIntegration
- Documentation:Deployment
- HowTos:HowTo
Choose an integration path
Use this section to find the relevant documented integration topic for your current task.
Choose an integration path
| If you need to... | Start here |
|---|---|
| Connect a single-page application with Turnkey | SPA Integration with Turnkey |
| Work with REST APIs | REST API Integration |
| Work with SOAP | SOAP Protocol Overview |
| Expose REST services | Exposing REST Services |
| Work with Web APIs | Web API Integration |
| Import data from SQL Server | SQL Server Data Import |
| Import XML or JSON data | XML and JSON Import |
| Import SQL data with associations | SQL Import with Associations |
| Work with data convergence | Data Convergence Techniques |
| Integrate Excel data | Excel Data Integration |
| Configure an authentication or identity-related integration | Understanding OpenIdConnect, OAuth2 Integration, Azure AD with OpenID, JWT Authentication, ASP.NET Identity Integration, or Header-Based Authentication |
| Integrate Swish, OpenAI, or Slack | Swish Payment Integration, OpenAI Integration, or Slack Web Hook Integration |
See also
Interoperability with external systems
Interoperability with external systems
MDriven documentation includes integration guidance for connecting applications with external systems and services, handling data import and export, and addressing authentication and security needs.
Find the relevant integration topic
Choose the documentation area that matches the integration need:
| Integration need | Documented topics |
|---|---|
| Authentication and security | BankID integration, OpenID Connect, OAuth2, Azure AD with OpenID, single sign-on, JWT authentication, ASP.NET Identity integration, and header-based authentication. |
| External APIs and services | SPA integration with Turnkey, REST API integration, SOAP protocol overview, exposing REST services, and Web API integration. |
| Data import and export | SQL Server data import, XML and JSON import, SQL import with associations, data convergence techniques, and Excel data integration. |
| Third-party services | Swish payment integration, OpenAI integration, and Slack web hook integration. |
Consider the exposure of client-facing integrations
When information or actions are exposed to a client, the documentation describes the ViewModel as a way to section information for a specific need and avoid revealing more than necessary. It also describes a Streaming ViewModel approach in which the client receives action names and requests that the server execute an action, rather than receiving the action implementation.
This is relevant when designing integrations that expose information or operations to users, because client-side applications can be inspected or imitated. Review the security implications of the selected integration design before exposing data or actions.
Next steps
- Identify whether the need concerns authentication, an external API or service, data import/export, or a named third-party integration.
- Select the corresponding guide from Documentation:Integration.
- Review the selected guide and the integration best-practices material before implementing the connection.