GraphQL Server for Visma Business

Data model extensions (DMEs)

Your own tables and fields from the Visma Business installation, right in the schema.

A Visma Business installation can extend the data model with contributions: new tables, new columns on core tables, and relations between them. This server serves them exactly the way it serves the core model. A consumer cannot tell a contributed field from a core one.

{
  order(where: { ole_Priority: { gt: 2 } }, order: [{ ole_Priority: DESC }]) {
    nodes { orderNo ole_ExternalRef ole_Priority }
  }
  ole_ProductReview(where: { ole_Rating: { gte: 4 } }) {
    nodes { ole_ReviewNo ole_Description joinup_Product_via_OLE_ProductReview_Product { description } }
  }
  product { nodes { joindown_OLE_ProductReview_via_OLE_ProductReview_Product(order: [{ ole_Rating: DESC }]) { ole_Rating } } }
}

mutation {
  order_update(orderNo: 1, order: { ole_ExternalRef: "X-1" }) { ole_ExternalRef }
  ole_ProductReview_create(ole_ProductReview: { ole_ProductNo: "1001", ole_Rating: 5 }) { ole_ReviewNo }
}

Per installation, read at startup

Contributions are not part of the build. One build serves every customer. At startup the server finds the installation’s contributions and merges them into the core model. It takes the first of these it finds:

  1. Business:PluginsXml, when set: a Plugins.xml (a share, when Visma Business runs on another machine), or none for the core model only.
  2. A Plugins folder next to the server. The easy way when the server runs on another machine than Visma Business: copy the DME files into it - or Visma’s whole Plugins folder.
    • With a Plugins.xml in it, that names the contributions as below. Paths in it that point at the Visma machine (C:\Program Files (x86)\...) are looked for next to Plugins.xml instead, so a copied folder works as it is.
    • Without one, every DME file in the folder is used: every *.xml whose root element is ModelContribution. Anything else there is ignored.
  3. Visma Business on this machine, where its installer recorded it in the registry: HKLM\SOFTWARE\WOW6432Node\Visma\Visma Business\CurrentVersion\Miscellaneous, PROG_PATH plus PLUGINS_PATH. Not installed here: the core model only.

The log says which it used (Data model extensions from ...). From a Plugins.xml the server takes what Visma Business loads:

  • <Model path="..."/> entries, except the core model’s own entry and any with isActive="False"
  • every *.xml file in an <IncludeFolder>
  • %VBUS_PROG_PATH% resolves to the folder that holds Plugins

A copy goes stale when the customer adds or changes a DME: copy it again and restart the service. That is safe either way round, as the next paragraph explains.

Every contributed table and column is checked against the database (INFORMATION_SCHEMA) at startup. Anything the database lacks, such as a copy of the files that is ahead of the database or a DME whose upgrade has not been run, is left out with a warning in the log, so it never shows up as failing SQL. A new or changed DME needs a restart of this service.

A DME reaches the database through Visma Business only: activate it in Plugins.xml, then run VBus.exe /XUPGRADE /XNOPROMPTSYSTEMUPGRADE /XDB_UPGRADE_PROGRESS_ON_STD_OUT (or open Visma Business and accept the upgrade). This server never alters the database.