The Components Set JsonC file
The structure of a Component Package JSON file
Last updated
The structure of a Component Package JSON file
Last updated
A Components Set is a JsonC
file, which is a Json file that allows Comments.
A Package consists of three main parts:
Dependencies are not supported right now, as of v 4.2.0
1 Header
1..n Components
0..n Dependencies
{
"header" : { },
"components" : [ ],
"dependencies": [ ]
}
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" ] }
]
}
descriptionA
stands for Description Array to support multiple lines in a description. (JSON does not support multi line strings.)
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"
}
]
During run-time AtomShpere Components may require other Components to run properly, like process routes or API Components.
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"
},
{ ... }
]
}]
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
},
deploy
boolean
If set to true the component (and all its children) will be deployed - recognized by DEPLOY EXEC command. Default: true.
getChildren
enum
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 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
}
see Default: dependent