get started| features| pricing| docs| login

Project Source Code

Each project in Instalink can be fully described by YAML formatted source code. Accessing the source code makes it possible to perform advanced operations including copy and paste, reparenting actions, find and replace, etc. The source code can be accessed by clicking the "Code" button at the top of the project management view.

Editing Project Source Code

Generally it is NOT recommended to directly edit the source code of a project as most all common project editing operations can be performed within the user interface. Editing project source code should be done with caution. However, it is always possible to revert any changes to the project using the project history feature.

Project source code may contain the following top level sections.

project

The following properties are accessible within project scope of the source code.

Project Example

    
project:
  active: true
  basePath: /cards
  buildNumber: 82
  name: Card Game
  versionNumber: 0.0.0

processes

All actions defined in the project are contained within the "processes" section of the source code. Each processes object follows the following general format:

    
  [ACTION_ID]:
    [ACTION_TYPE]:
      [...ACTION_PROPERTIES...]

ACTION_ID
The ACTION_ID key should contain the internal GUID identifier for the action. This property is always automatically generated by the system. Once the action is saved, the identifier is maintained by the system. The original action is considered deleted if the ACTION_ID key is changed in the source code. When inserting new actions, any value may be used as the ACTION_ID key. The only requirement is that the value is unique within the scope of the project actions and all references to the inserted ACTION_ID key are consistent. For example if "A" used as the ACTION_ID, then everywhere else in the project that this action is referenced should also refer to the key "A". Once the project source code is saved, the key used for the ACTION_ID is always replaced by the system generated GUID. This makes it possible to copy any actions from any project to any other project.

ACTION_TYPE
The ACTION_TYPE key should always reference the internal identifier of the action type. The following are valid action types:

ACTION_PROPERTIES
A plurality of contextual action properties may be included in the ACTION_PROPERTIES section of a process record. Click on any of the ACTION_TYPE links above to view the properties that may be included in this section. The properties are contextual which means that any property that is not applicable to the selected ACTION_TYPE will be ignored.

In addition to the contextual action properties, the ACTION_PROPERTIES section also allows for properties that are globally applicable to any action type.

Processes Example

    
processes:
  5f515429ba023c80b756a1f9:
    LISTEN:
      customPath: /deck/draw
      description: if receive call at /deck/draw
      operator: IF
      recordIdentifierTemplate: 'Draw From Deck ${name}'
      status: 'ON'
      then:
        - 5f515498ba023c80b756a1fd
      UrlKey: 458ca289-3778-4eb7-8d41-b03cd246ff7e
  5f515498ba023c80b756a1fd:
    SESSION_READ:
      description: 'then read session from deck:${name}'
      fields:
        5f5154c7ba023c80b756a1fe:
          key: cards
          value: ''
        5f5154c7ba023c80b756a1ff:
          key: hands
          value: ''
      namespace: 'deck:${name}'
      operator: THEN
      outKey: deck
      status: 'ON'
      then:
        - 5f5154dcba023c80b756a200
  5f5154dcba023c80b756a200:
    CHECK_DATA:
      conditions:
        5f515503ba023c80b756a201:
          checkKey: deck.cards.length
          compareAs: GREATER_THAN
          findIn: parameters
          value: '0'
      description: then if deck.cards.length greater than 0
      else:
        - 5f515507ba023c80b756a202
      operator: THEN
      status: 'ON'
      then:
        - 5f51552fba023c80b756a204
  5f515507ba023c80b756a202:
    RESPOND_FAILURE:
      description: 'else respond with 400 error, No more cards to draw'
      errorMessage: No more cards to draw
      fields:
        5f515521ba023c80b756a203:
          key: error
          value: No more cards to draw
      logError: false
      logSuccess: false
      operator: ELSE
      status: 'ON'
  5f51552fba023c80b756a204:
    TRANSFORM_DATA:
      description: then Draw N Cards
      operator: THEN
      status: 'ON'
      then:
        - 5f515721ba023c80b756a20b
      transforms:
        5f515603ba023c80b756a205:
          arg1: '0'
          arg2: '${amount}'
          fromKey: deck.cards
          toKey: hand
          transformAs: ARRAY_SUB
        5f5156ceba023c80b756a209:
          arg1: '${amount}'
          arg2: '52'
          fromKey: deck.cards
          toKey: deck.cards
          transformAs: ARRAY_SUB

vars

The vars section contains all the project variables attached to the project. Each var is an object with a GUID as the key and the following properties.

Vars Example

    
vars:
  6169e6615a39509c64af186d:
    hidden: false
    key: test
    value: THIS IS A TEST VALUE
  6169e6615a39509c64af186e:
    hidden: true
    key: password
    value: xxxxxxxxxx

connectors

The connectors section contains all the project connectors that are attached to the project. Each connector is an object with a GUID as the key and the following properties.

Connectors Example

    
connectors:
  6169e8a8f1ba8d9d268b85d7:
    connectorId: 60145bc9969bd3ebaea1d2c6
    connectorVersionId: 60145be3969bd3ebaea1d2c7

authorizations

The authorizations section contains all the authorization records that are attached to the project. Each authorization record is an object with a GUID as the key and the following properties.

Authorizations Example

    
authorizations:
  66b29802ea82f66a2a7ce9f8:
    basicAuth_password: xxxxxxxxxx
    basicAuth_username: username
    consumerauth_user: ''
    description: Basic Auth
    instalinkauth_user: ''
    oauth1_consumerKey: ''
    oauth1_consumerSecret: xxxxxxxxxx
    oauth1_realm: ''
    oauth1_tokenKey: ''
    oauth1_tokenSecret: xxxxxxxxxx
    type: Basic

databases

The authorizations section contains all the database connection definitions that are attached to the project. Each database connection definition is an object with a GUID as the key and the following properties.

Databases Example

    
databases:
  66ba58053f35ff13e0cc2190:
    databaseName: testdb
    engine: mysql
    host: localhost
    name: Test DB
    options: ''
    password: xxxxxxxxxx
    port: '3306'
    requestTimeout: 15000
    user: root

secrets

The secrets section contains all the secret keys that are attached to the project. Secrets are generally encrypted keys that are stored with encryption at rest. In the project source code, each secret record is an object with a GUID as the key and the following properties. It is not advisable or intended for users to directly modify project secrets from the source code. When copying and pasting a project that contains a secret key, it will be necessary to update the properties of the newly created key record using the Instalink interface.

Secrets Example

    
secrets:
  67d8a7272a26a766161bf57a:
    dataCipher: xxxxxxxxxx
    encryptionKeyId: xxxxxxxxxx
    label: TEST secret
    secretType: SSH_KEY
    sshPassphraseCipher: xxxxxxxxxx

Important Things to Note

  1. The system will never directly store the raw edits that a user makes to the source code. Instead the system will parse and interpret the raw source code and then generate a new clean representation of the project according to its own internal logic and validation rules.
  2. To maintain consistency in the source code when comparing versions, the system will always order the top level sections in the following order: project, processes, vars, connectors, authorizations, databases, and secrets. The system will accept these properties out of order on a raw edit, but will always return the sections in this order.
  3. To maintain consistency in the source code when comparing versions, the system will always sort sub-record objects alphabetically by their key. The system will accept sub-record objects out of order on a raw edit, but will always return the file with the keys sorted alphabetically.
  4. To maintain consistency in the source code when comparing versions, the system will always sort objects alphabetically by their key. The system will accept object properties out of order on a raw edit, but will always return the file with the properties sorted alphabetically.
  5. The project source code conforms to standard YAML formatting. It supports the ability to include arrays, objects, a and inline documents. Please refer to online resources on YAML formatting for additional details on the syntax that should be used when editing project source code.
  6. All properties on a sub-record are optional. If a property is not included in the source code, then it is assumed to have the default value. The source code will not display the property if it has the default value in most circumstances.
privacy policy
terms of service