Best practices

Best practices

The following information presents the recommended best practices for using and maintaining your MVS Toolkit system.

Back Up Your Web Services

  • Export your web services every time you make a change.
  • You can copy the web service export file into a D3 data file.
  • Web service data is stored in the <MVS.Install.Directory>/server/database directory which can be added to your backup scheme.

MVS Toolkit Version

Make sure all Toolkit clients and servers are running the same version of the Toolkit (preferably the latest version). Failure to do so can result in operational inconsistencies and errors. For the latest version, see ourStatus Sheets.

Unique Server Names

  • Use unique names for your MVS Web Service Providers and MV Servers (D3/mvBase).
  • Develop and use a naming convention. For example: For a server named Acmeserver that hosts both the MVS Web Server and a D3 or mvBase database server, name the Web Service Provider Acmeserver_mvs and name the MV Server Acmeserver_d3 or Acmeserver_mvB. This will avoid confusion when communicating with others about your web service environment and makes it easier to programmatically change server names in a web service export file prior to importing web services.

Host Names

  • NEVER use “localhost” as a hostname.

    While this works fine on test systems where the IDE, the MV server, and all of the clients (including browsers and applications) all reside on the same machine, the use of “localhost” will be problematic when you start distributing or testing in a multi-machine environment.

  • If you cannot use a DNS-resolvable name, use an IP address.
  • If you prefer not to bury the IP address in all of your definitions, use the “hosts” files on all machines involved to resolve names to IP addresses.
  • Make sure you can ping the host by your chosen name/address from any machine hosting the client or server. Remember, if you cannot ping it, the client/server cannot connect to it.

Avoid AQL-based Web Service Operations

  • Using subroutines rather than AQL statements gives you more control over your responses and gives you greater ability to validate request data and enforce security.
  • AQL responses as implemented in the Toolkit suffer from over-nesting.

Subroutine Error Handling

  • All subroutine logic flow MUST ultimately reach a RETURN statement.
  • Where you might use END, DEBUG, ABORT, or STOP in a normal subroutine when an error occurs, this will cause the MVSP connection to hang for no clear reason.
  • Log errors to a file and/or pass errors back to the web service via a “status” argument in your subroutine.

Logs

Regularly review your Client, Server, and D3/mvBase error logs. It is recommended that you purge these logs on a regular basis to keep their sizes more manageable. Also, smaller logs are easier to review and send to Rocket D3MV Support if requested.

  • The MVS server logs are in the <MVS.Install.Directory>/server/logs directory.
  • The MVS client log is in the /users/<User>/MVTool/.metadata directory.

Separate MVS-specific D3/mvBase Account

  • In D3/mvBase, set up a separate account from which to run your web services.
  • Use Q-pointers within that account to point to your real data accounts.
  • Create a BP file local to that account to hold your MVS-specific subroutines.
  • When using subroutines from your existing application account, catalog only the subroutines you are using (not every subroutine in the existing application’s normal BP file).

Source Control

  • There is no source control utility within the Toolkit. While it is possible to deploy the IDE Client to multiple machines, it is not recommended unless you have addressed the issue of source control. We instead recommend installing the IDE client on one machine and using remote desktop to access the client on that machine.
  • When there are multiple developers working on the same system, make sure they communicate and do not step on each other's work.