--- title: "Read the data interface of a method version." method: GET path: "/component-registry/methods/{componentVersionReference}/data-interface" tags: ["Component Registry"] --- # Read the data interface of a method version. `GET /component-registry/methods/{componentVersionReference}/data-interface` ## Path parameters - `componentVersionReference` string, required ## Response `200` Ok - ComponentRegistryDataInterface — Description of the input and output data of a method or a workflow. - `input` ComponentRegistryDataDescription[] - `dataProviderType` 'INTERNAL' | 'EXTERNAL' — Identifies if a data is - `INTERNAL`: data is stored and managed by `data-repository` service or - `EXTERNAL`: data is stored and managed by an external service. Only a reference for it is stored in `data-repository` service. - `dataTypeFilter` union - WorkflowsBooleanValue — Value interface is the root of the value model type hierarchy. Value models store the computation model of values. The models are defined by the developer, for convenience through a DSL composed of receiver and extension functions and other Kotlin language constructs. When the build runs the definition of the value model, it gets serialized into a JSON representation and that is the artifact of the build. These JSONs are persisted into the database and loaded by the workflow engine for the evaluation of the values. Once values are computed they get stored as data and used by methods or clients to show data to the user. Value models and data models adhere to the same schema defined by the developer in DSSL, just they have a different implementation due to their different roles. Below we define the central repository of value models. These are all part of the framework, available to the workflow engine as well. They provide atomic types and composition mechanisms via containers and the compound value model class. These are in sync with the building blocks in DSSL. User defined types via DSSL schemas are based on the compound value model. The generated value models are available only at build time to the user to define the value computation logic in a type-safe way, meanwhile at runtime in the workflow engine only the compound value model is present. The single value resolution function of this interface is the one used by the workflow engine to execute the value computation. All value models implement this in their own way. The result is always a JSON node, which can be either a single node or an entire tree of nodes behind it. Value model types below are organized into groups based on their parent type, essentially following the hierarchy in a flattened way. The type names - which get into the serialized JSON representation - also follow this structure, where levels are separated with a colon (`:`). By convention names composed of multiple words are presented with snake-case and these rules are followed as a naming convention: * `operation` for operators (both unary and binary, e.g. plus, minus, not...), * `comparison` for comparators (equal, not equal, less than), * `function` for the general case. - `value_model_type` string, required - unknown - `dataValidationRuleSet` union - ComponentRegistryValidationRuleSet — Set of validation rules. It can be associated to for example a workflow type configuration schema or a method configuration schema. - `rules` ComponentRegistryValidationRule[] - `cases` ComponentRegistryValidationRuleCase[] - `code` string - `condition` WorkflowsBooleanValue — Value interface is the root of the value model type hierarchy. Value models store the computation model of values. The models are defined by the developer, for convenience through a DSL composed of receiver and extension functions and other Kotlin language constructs. When the build runs the definition of the value model, it gets serialized into a JSON representation and that is the artifact of the build. These JSONs are persisted into the database and loaded by the workflow engine for the evaluation of the values. Once values are computed they get stored as data and used by methods or clients to show data to the user. Value models and data models adhere to the same schema defined by the developer in DSSL, just they have a different implementation due to their different roles. Below we define the central repository of value models. These are all part of the framework, available to the workflow engine as well. They provide atomic types and composition mechanisms via containers and the compound value model class. These are in sync with the building blocks in DSSL. User defined types via DSSL schemas are based on the compound value model. The generated value models are available only at build time to the user to define the value computation logic in a type-safe way, meanwhile at runtime in the workflow engine only the compound value model is present. The single value resolution function of this interface is the one used by the workflow engine to execute the value computation. All value models implement this in their own way. The result is always a JSON node, which can be either a single node or an entire tree of nodes behind it. Value model types below are organized into groups based on their parent type, essentially following the hierarchy in a flattened way. The type names - which get into the serialized JSON representation - also follow this structure, where levels are separated with a colon (`:`). By convention names composed of multiple words are presented with snake-case and these rules are followed as a naming convention: * `operation` for operators (both unary and binary, e.g. plus, minus, not...), * `comparison` for comparators (equal, not equal, less than), * `function` for the general case. - … - `details` object, nullable - `message` WorkflowsStringValue — Value interface is the root of the value model type hierarchy. Value models store the computation model of values. The models are defined by the developer, for convenience through a DSL composed of receiver and extension functions and other Kotlin language constructs. When the build runs the definition of the value model, it gets serialized into a JSON representation and that is the artifact of the build. These JSONs are persisted into the database and loaded by the workflow engine for the evaluation of the values. Once values are computed they get stored as data and used by methods or clients to show data to the user. Value models and data models adhere to the same schema defined by the developer in DSSL, just they have a different implementation due to their different roles. Below we define the central repository of value models. These are all part of the framework, available to the workflow engine as well. They provide atomic types and composition mechanisms via containers and the compound value model class. These are in sync with the building blocks in DSSL. User defined types via DSSL schemas are based on the compound value model. The generated value models are available only at build time to the user to define the value computation logic in a type-safe way, meanwhile at runtime in the workflow engine only the compound value model is present. The single value resolution function of this interface is the one used by the workflow engine to execute the value computation. All value models implement this in their own way. The result is always a JSON node, which can be either a single node or an entire tree of nodes behind it. Value model types below are organized into groups based on their parent type, essentially following the hierarchy in a flattened way. The type names - which get into the serialized JSON representation - also follow this structure, where levels are separated with a colon (`:`). By convention names composed of multiple words are presented with snake-case and these rules are followed as a naming convention: * `operation` for operators (both unary and binary, e.g. plus, minus, not...), * `comparison` for comparators (equal, not equal, less than), * `function` for the general case. - … - `multiLanguageMessage` object, nullable - `severityLevel` 'ERROR' | 'WARNING' — Severity levels for reporting validation results. - `code` string - `description` string, nullable - `multiLanguageDescription` object, nullable - `multiLanguageName` object, nullable - `name` string - `valueReference` union - WorkflowsConfigValueReference — Reference to a value which can be resolved using a particular context. - … - WorkflowsDataPresenceReference — Reference to a value which can be resolved using a particular context. - … - WorkflowsDataValueReference — Reference to a value which can be resolved using a particular context. - … - WorkflowsGeneralMetadataValueReference — Reference to a value which can be resolved using a particular context. - … - WorkflowsIteratorReference — Reference to a value which can be resolved using a particular context. - … - WorkflowsMetadataValueReference — Reference to a value which can be resolved using a particular context. - … - unknown - `doc` string, nullable - `label` string, nullable - `multiLanguageDoc` object, nullable - `multiLanguageLabel` object, nullable - `name` string - `optional` boolean - `parameters` ComponentRegistryParameterDescription[] - `dataType` string - `doc` string, nullable - `label` string, nullable - `multiLanguageDoc` object, nullable - `multiLanguageLabel` object, nullable - `name` string - `type` string - `output` ComponentRegistryDataDescription[] - `dataProviderType` 'INTERNAL' | 'EXTERNAL' — Identifies if a data is - `INTERNAL`: data is stored and managed by `data-repository` service or - `EXTERNAL`: data is stored and managed by an external service. Only a reference for it is stored in `data-repository` service. - `dataTypeFilter` union - WorkflowsBooleanValue — Value interface is the root of the value model type hierarchy. Value models store the computation model of values. The models are defined by the developer, for convenience through a DSL composed of receiver and extension functions and other Kotlin language constructs. When the build runs the definition of the value model, it gets serialized into a JSON representation and that is the artifact of the build. These JSONs are persisted into the database and loaded by the workflow engine for the evaluation of the values. Once values are computed they get stored as data and used by methods or clients to show data to the user. Value models and data models adhere to the same schema defined by the developer in DSSL, just they have a different implementation due to their different roles. Below we define the central repository of value models. These are all part of the framework, available to the workflow engine as well. They provide atomic types and composition mechanisms via containers and the compound value model class. These are in sync with the building blocks in DSSL. User defined types via DSSL schemas are based on the compound value model. The generated value models are available only at build time to the user to define the value computation logic in a type-safe way, meanwhile at runtime in the workflow engine only the compound value model is present. The single value resolution function of this interface is the one used by the workflow engine to execute the value computation. All value models implement this in their own way. The result is always a JSON node, which can be either a single node or an entire tree of nodes behind it. Value model types below are organized into groups based on their parent type, essentially following the hierarchy in a flattened way. The type names - which get into the serialized JSON representation - also follow this structure, where levels are separated with a colon (`:`). By convention names composed of multiple words are presented with snake-case and these rules are followed as a naming convention: * `operation` for operators (both unary and binary, e.g. plus, minus, not...), * `comparison` for comparators (equal, not equal, less than), * `function` for the general case. - `value_model_type` string, required - unknown - `dataValidationRuleSet` union - ComponentRegistryValidationRuleSet — Set of validation rules. It can be associated to for example a workflow type configuration schema or a method configuration schema. - `rules` ComponentRegistryValidationRule[] - `cases` ComponentRegistryValidationRuleCase[] - `code` string - `condition` WorkflowsBooleanValue — Value interface is the root of the value model type hierarchy. Value models store the computation model of values. The models are defined by the developer, for convenience through a DSL composed of receiver and extension functions and other Kotlin language constructs. When the build runs the definition of the value model, it gets serialized into a JSON representation and that is the artifact of the build. These JSONs are persisted into the database and loaded by the workflow engine for the evaluation of the values. Once values are computed they get stored as data and used by methods or clients to show data to the user. Value models and data models adhere to the same schema defined by the developer in DSSL, just they have a different implementation due to their different roles. Below we define the central repository of value models. These are all part of the framework, available to the workflow engine as well. They provide atomic types and composition mechanisms via containers and the compound value model class. These are in sync with the building blocks in DSSL. User defined types via DSSL schemas are based on the compound value model. The generated value models are available only at build time to the user to define the value computation logic in a type-safe way, meanwhile at runtime in the workflow engine only the compound value model is present. The single value resolution function of this interface is the one used by the workflow engine to execute the value computation. All value models implement this in their own way. The result is always a JSON node, which can be either a single node or an entire tree of nodes behind it. Value model types below are organized into groups based on their parent type, essentially following the hierarchy in a flattened way. The type names - which get into the serialized JSON representation - also follow this structure, where levels are separated with a colon (`:`). By convention names composed of multiple words are presented with snake-case and these rules are followed as a naming convention: * `operation` for operators (both unary and binary, e.g. plus, minus, not...), * `comparison` for comparators (equal, not equal, less than), * `function` for the general case. - … - `details` object, nullable - `message` WorkflowsStringValue — Value interface is the root of the value model type hierarchy. Value models store the computation model of values. The models are defined by the developer, for convenience through a DSL composed of receiver and extension functions and other Kotlin language constructs. When the build runs the definition of the value model, it gets serialized into a JSON representation and that is the artifact of the build. These JSONs are persisted into the database and loaded by the workflow engine for the evaluation of the values. Once values are computed they get stored as data and used by methods or clients to show data to the user. Value models and data models adhere to the same schema defined by the developer in DSSL, just they have a different implementation due to their different roles. Below we define the central repository of value models. These are all part of the framework, available to the workflow engine as well. They provide atomic types and composition mechanisms via containers and the compound value model class. These are in sync with the building blocks in DSSL. User defined types via DSSL schemas are based on the compound value model. The generated value models are available only at build time to the user to define the value computation logic in a type-safe way, meanwhile at runtime in the workflow engine only the compound value model is present. The single value resolution function of this interface is the one used by the workflow engine to execute the value computation. All value models implement this in their own way. The result is always a JSON node, which can be either a single node or an entire tree of nodes behind it. Value model types below are organized into groups based on their parent type, essentially following the hierarchy in a flattened way. The type names - which get into the serialized JSON representation - also follow this structure, where levels are separated with a colon (`:`). By convention names composed of multiple words are presented with snake-case and these rules are followed as a naming convention: * `operation` for operators (both unary and binary, e.g. plus, minus, not...), * `comparison` for comparators (equal, not equal, less than), * `function` for the general case. - … - `multiLanguageMessage` object, nullable - `severityLevel` 'ERROR' | 'WARNING' — Severity levels for reporting validation results. - `code` string - `description` string, nullable - `multiLanguageDescription` object, nullable - `multiLanguageName` object, nullable - `name` string - `valueReference` union - WorkflowsConfigValueReference — Reference to a value which can be resolved using a particular context. - … - WorkflowsDataPresenceReference — Reference to a value which can be resolved using a particular context. - … - WorkflowsDataValueReference — Reference to a value which can be resolved using a particular context. - … - WorkflowsGeneralMetadataValueReference — Reference to a value which can be resolved using a particular context. - … - WorkflowsIteratorReference — Reference to a value which can be resolved using a particular context. - … - WorkflowsMetadataValueReference — Reference to a value which can be resolved using a particular context. - … - unknown - `doc` string, nullable - `label` string, nullable - `multiLanguageDoc` object, nullable - `multiLanguageLabel` object, nullable - `name` string - `optional` boolean - `parameters` ComponentRegistryParameterDescription[] - `dataType` string - `doc` string, nullable - `label` string, nullable - `multiLanguageDoc` object, nullable - `multiLanguageLabel` object, nullable - `name` string - `type` string --- [API](https://skmtc.net/simscale/apis/simscale-api.md) · [All operations](https://skmtc.net/simscale/apis/simscale-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/simscale/simscale-api/revisions/53223abaceb7/schema)