Deployment

When your mathematical model is ready to be used in your application, you should create a build from your project. The build process will transform your model into executable source code for the selected build targets.

Build Configuration

With build configurations you can customize the build process. A build configuration selects the build targets to be used and the calculation groups to be included in the results.

By default all of your calculations will be included, in several cases this may not be what you want. You may want to configure what calculations your client applications can call. Instead of setting this up per client application you can configure this per build configuration by selecting exactly which calculation groups get included in the builds and which build targets you would like to provide.

Every build configuration has it’s own build history, creating builds and releasing them do not affect other configurations’ builds.

Changing a build configuration will not change previous builds under that configuration, it will be used only for future builds.

../_images/buildConfig.svg

Configuration example

See it in action:

Id-s

Some entities must be accessible in the resulting code. Their names are not restrictive enough to be used in source code, so you will need to assign them id-s that match a certain format. They may only contain alphanumeric characters and only letters as the first character. (/^[a-zA-Z]+[a-zA-Z0-9]*$/)

Application developers will refer to these entities by using their id-s when they invoke your calculations.

Build workflow

Every time you build your project, the result will overwrite your last build named the draft build. This is intended for iterating until you reach a state that you would like to publish. This build is not recommended to be used in production environments as it may change unexpectedly. You should use released builds as those will not be overwritten.

To release a build you must give it a version that must follow the basic rules of semantic versioning:

Given a version number MAJOR.MINOR.PATCH, increment the:

  • MAJOR version when you make incompatible API changes,
  • MINOR version when you add functionality in a backwards-compatible manner, and
  • PATCH version when you make backwards-compatible bug fixes.

Your calculations’ input variables and output variables (more precisely their id-s) define your API. Formulative examines your calculations and determines the smallest version incrementation needed for your next release to not break live clients.

The rules are the following:

MAJOR bump is needed when:
  • the project’s id changed
  • a calculation group was deleted or it’s id changed
  • a calculation was deleted or it’s id changed
  • a previously existing calculation now needs additional input variables
  • a calculation response now contains less output variables than before
MINOR bump is needed when:
  • a new calculation group was created
  • a new calculation was created
  • a previously existing calulation now needs less input variables
  • a calculation response now contains more output variables than before

Integrator access

This feature is only available for organizations. Learn more about organizations

The Integrator organizational role was designed to give minimal access to project builds required for a developer to integrate with your calculation API. Integrators have access to the following information:

  • list of authorized client applications providing client credentials for hosted web services
  • downloadable build results for the authorized client applications

Users with a Deployer role may view exactly what Integrators would see under the Integration page of a client application.

Invoking calculations

There are multiple ways to invoke calculations. Choose the one that best suits your needs from the following scenarios. If none of these meet your requirements, feel free to get in touch with us to find a solution.

  1. Calling our hosted web services
  2. Using the JavaScript build in JavaScript applications
  3. Using the JavaScript build in non-JavaScript applications

1. Calling Formulative hosted web services

Formulative provides easy deployment of highly available auto-scalable web services generated from your mathematical model hosted on the Amazon Web Services (AWS) platform.

For details check out Concepts/Web service hosting

2. Using the JavaScript build in JavaScript applications

The JavaScript build will contain a bundled .js file that can be easily loaded in any JavaScript project.

Keep in mind that JavaScript source code in browsers may be freely inspected by anyone thus including confidential calculations in front-end applications is not advised. Even tough we obfuscate the generated code it does not make it impossible to reverse engineer. Furthermore native applications may also be incapable of storing these scripts securely, it’s up to the application developers to provide a suitable execution environment.

Wrapping the build in a Node.js web service is one way to secure your calculation details. The express.js web framework for example is a good choice to create a robust HTTP API quick and easy.

Learn more:

3. Using the JavaScript build in non-JavaScript applications

For many languages bindings can be found for V8 - Google’s open source high-performance JavaScript engine used in Google Chrome (e.g.: J2V8 for Java bindings)

On iOS, macOS, tvOS platforms Apple provides the JavaScriptCore Framework.

Formulative provides a couple of non-JavaScript build targets that you may select in your build configurations demonstrating these solutions.

Currently supported non-JavaScript build targets:

  • Java
  • Java (Android)
  • Objective-C
Learn more: