The Components Set JsonC file

The structure of a Component Package JSON file

A Components Set is a JsonC file, which is a Json file that allows Comments.

If you followed the recommended Installation and Setup procedure, you will find two example JsonC in your Workspace:

A Package consists of three main parts:

Dependencies are not supported right now, as of v 4.2.0

1. 1 Header

2. 1..n Components

3. 0..n Dependencies

{
  "header"      : { },
  "components"  : [ ],
  "dependencies": [ ]
}

Header

Not much to say about the Header. Just: it is for your information, only. The intention of the header is descriptive and whatever you put there, it is ok!

 "header": { 
   "name": "April 21 - Sprint 03 Updates",
    "descriptionA": [
      "Service Request clone documents",
      "https://<JIRAUrl>/browse/DS-<ticketNo>"
    ],
   "packageVersions": [
      { "date": "2021-04-22", "author": "msc", "changes": [ "Created" ] }
    ]
  }

Don't use line breaks in any string. Quotes should be on the same line, always!

descriptionA stands for Description Array to support multiple lines in a description. (JSON does not support multi line strings.)

Components

This is the main section where you refer to the components you want to use in the Package. The component is referenced by its ComponentId. Optional, but recommended, is the component's name as the Hint, for better readability.

"components": [
  {
    "hint": "Database Basics: Insert into Multiple Tables with Commit Options",
    "id": "6f09acfa-5226-471c-b241-f180bffea9a4"
  },
  {
    "hint": "Database Basics: Simple Insert, Update Examples",
    "id": "d1226373-3719-49bb-9eb3-81d3613c6c2d"
  }
]

Nested Components in a Package

During run-time AtomShpere Components may require other Components to run properly, like process routes or API Components.

API Component with required processes

If you deploy an API Component, all referenced process must be deployed and versioned separately. This can be a pain, to ensure that all referenced processes are always deployed properly when the API changes.

The good thing is, a Component Package supports nested /child packages that inherit the settings of its parent.

"components": [
{
  // API Component
  "hint": "APIDemo - /ws/rest/Demo",
  "id": "1df76799-7eec-43b9-a9d0-965e3c38ba82",
  
  "components": 
  [    // Children: implementing processes
    {
      "hint": "Test.POST",
      "id": "a02a5a71-b72e-4664-90b6-1cb92a4de5de"
    },
    {
      "hint": "Test 2.GET",
      "id": "a02a5a71-...-1cb92a4de5de"
    },
    { ...  }
  ]
}]

Component Properties

A component supports multiple properties. A parent component inherits its properties to its children, unless a child overrides it.

"components": [
    { "hint": "ws/rest/Demo",
      "id": "1df76799-7eec-43b9-a9d0-965e3c38ba82",
      
      "getChildren" : "none", "deploy": false
    },

Property Name	Value	Description
deploy	boolean	If set to true the component (and all its children) will be deployed - recognized by DEPLOY EXEC command. Default: true.
getChildren	enum	see /children argument Default: dependent

Please notice, child components inherit the properties from their parent component, unless they explicitly specify their own property.

{ 
  "hint": "Parent Component",
  
  // The parent component does not specify a component ID
  // and it simply server as a 'control' component to define 
  // properties for all its children.
  
  "deploy": false,        // do not deploy any child component
  "getChildren": "none",  // do not retrieve any from service      
  
  "components":   // Children components
  [
    {
      "hint": "FLOW.ServiceRequest/FetchMO",
      "id": "6f09acfa-5226-471c-b241-f180bffea9a4"
      // inherits parent properties
    },
    {
      "hint": "FLOW.Load Middle Office Users",
      "id": "d1226373-3719-49bb-9eb3-81d3613c6c2d",
      // Override parent settings
      "deploy": true,             // deploy this component
      "getChildren": "dependent", // COMP GET component incl all references
    },
    ...

Dependencies

Dependencies refer to other Packages. Dependencies are useful if you want to use library packages or if you want to create one deployment package at the end of the Sprint, for example, that references multiple other Packages, one from each developer - consolidate work packages.

"dependencies": [
{
  "packageFileName": "lib\ErrorHandler\iPack.jsonc",
  "getAction": "skip",
  "delpoy": false
}