TMF Tools - Xyna-Factory/xyna GitHub Wiki
General
The TMF Tools split into 2 applications:
- TMF Mapping Tools: Provide help mapping between TMF640/633 data model and a service based Xyna data model
- TMF Validation Tools: Validate TMF640 Services against TMF633 Service Specifications
These can be used separately as well as together.
TMF Mapping Tools
The TMF Mapping Tools are based on the following assumptions:
- You want to implement TMF640 API but use a differently structured service data model in Xyna Data Types as the "backend"
- You are ok with using the TMFv4 extension of TMF633 and TMF640 that are present in the OAS schema files: (https://github.com/Xyna-Factory/xyna-factory/tree/main/modules/xfmg/tmf/datamodels)
- These extensions/changes include:
- Backport of TMFv5 typed characteristics
- Characteristics in ServiceRelationships
- ExternalIdentifiers
- Validation: Constraints and AllowedChanges
TMF Mapping Tools are designed to support the following use cases, including workflows for each of them to call from your TMF640 request handler workflows.
- "Instantiate" (xfmg.tmf640.InstantiateService): Map a TMF640 service representation to your own service data model in Xyna
- "Create Spec" (xfmg.tmf633.CreateServiceSpecification): Generate the TMF633 specification json for the corresponding services, based on the Xyna data types of the services
- "Transform" (xfmg.tmf640.TransformService): Reverse direction of 1)
There are also variants that use JSON documents as inputs/outputs where suitable instead of instances of OAS generated data types: InstantiateServiceJSON, TransformServiceJSON
Dependencies
- List
- RegExp
- Service_Activation_and_Configuration_Data_Model (OAS generated TMF640 data model)
- Service_Catalog_Management_Client (OAS generated TMF633 client) ** Service_Catalog_Management_Data_Model (OAS generated TMF633 data model - implicitely) ** OAS_Base (implicitely)
Usage
The typical steps to setup TMF Mapping Tools are:
- You generate the Service Provider application using the OAS Importer (Factory Manager) from the TMF 640 OAS schema file.
- You add TMF Tools and Service Provider as additional dependencies to your workspace
- You implement the OAS API "tmf640.provider.ServiceApi" and override the methods you need, for example "POST /service". In the Workflow implementing this method you call the "validation" and "instantiate" workflows from TMF Tools. Then you call the service activation logic based on your own data model.
- You instantiate the filter provided by the "Service Provider" application (and corresponding HTTP trigger). At runtime the filter will automatically find your ServiceApi subtype and invoke it.
For the TMF Mapping Tools to work you have to add Annotations to your own data model that tell the TMF Tools which Xyna data types are to be used as your services and how their fields/members are to be represented in TMF.
TMF Validation Tools
Compared to the TMF Mapping Tools the TMF Validation Tools use less assumptions. They are designed to validate TMF640 services, but do not depend on many specifics of the data model. The main Workflows are:
- "Validation" (xfmg.tmf640.validation.ValidateService): Validate TMF640 services against service specification, including Constraints
- Variant that does not retrieve specification dynamically: xfmg.tmf640.validation.ValidateServiceAgainstServiceSpecificationV3
- "Validate changes" (xfmg.tmf640.validation.ValidateAllowedChanges): Validate changes from previous "version" of service to changed "version" against white lists.
- "Set defaults" (xfmg.tmf640.SetDefaultsForMissingCharacteristics): Adds characteristics that are not present in a service if the specification provides a default for them
- JSON based variants: ValidateServiceJSON, ValidateServiceAgainstServiceSpecificationJSON, SetDefaultsForMissingCharacteristicsJSON
Dependencies
- List
- OAS_Base