1. SDC BL and Titan overview

2. Same transaction and different BLs
Titan opens transaction on first access (read, update) to graph per thread.
Application is responsible to close transaction in Titan.
SDC manages 2 types of transaction :
“logical” transaction - between lock element and release element.
Titan transaction
All Transactions are managed on BL level
Some times need to share transaction between BLs – manage transaction only on first BL level
For example :
BL1.f() -> BL2.f1()->BL2.f3()
The transaction will be opened and closed in BL1.
For these cases is used “old” mechanism – parameter in method.
Locking element in same way

3. For element Locking is used Titan
For element Locking is used Titan. SDC creates vertex with special unique id ( component unique id + postfix). This vertex created in separate transaction.
If another request try to lock element that already is locked the Titan throws Unique Constraint violation exception.
After all BL operations the element is unlocked - the vertex is deleted.
GraphLockOperation is responsible for locking/unlockig

4. Exist new transactional mechanism
Non locking transaction:
Locking transaction:

5. Transaction – Limitation.
methods must be public and must be called from external classes. Calling a method from inside the same class will not trigger the transaction manager.
Since spring transaction management abstraction assumes that an error occurred if an exception was thrown, returning an erroneous Either will not trigger a rollback. This means that legacy methods, which uses the Either type should still explicitly call the rollback method incase an error has occurred.
allows configuring many parameters for transaction handling. This is currently not supported (for example inner transactions, read- only transactions etc).
annotated method should have its first two parameters explicitly be: String componentId, ComponentTypeEnum componentType We can enhance the functionality of the locking aspect so different parameters can be supported.

6. Example for new Transactional mechanism : GroupBusinessLogicNew
Example for same transaction in BLs :
ResourceBusinessLogic -> LifecycleBusinessLogic

7. Model Each type of data is stored as json string in separate vertex.
Mapping data type to class defined in VertexTypeEnum
GraphVertex is wrapper of TitanVertex, contains all data
On metadata vertex part of properties stored as Titan
indexed properties ( used for search ) and all properties
as one property JSON string .
private Map<GraphPropertyEnum, Object> metadataProperties; //indexed properties
private Map<String, Object> metadataJson; //json of metadata
private Map<String, ? extends ToscaDataDefinition> json; //json of data or composition
Part of metadata properties is duplicated . BL update
metadataProperties. Before update vertex the json field will be synchronized
with new values. Method updateMetadataJsonWithCurrentMetadataProperties in GraphVertex

8. Data is saved as JSON string.
Usually all relevant data saved as one json :
Groups and their properties
Policies and their properties
Artifacts and heat parameters
Capabilities and their properties are saved as 2 different jsons.

9. Add member to resource Define data structure
The class represented data must extends ToscaDataDefinition according to naming convention
Model level
BL level
Add mapping vertex data type to VertexTypeEnum
MY_NEW_TYPE(“myNewType",NewTypeDataDefinition.class),
Add new edge label EdgeLabelEnum
MY_NEW_TYPE

10. Exist more complicated structures. For example :
This model is used for simple cases : Map<String, data definition >.
Exist more complicated structures. For example :
Isntance_id :{
property_name : {…} }
Map<String, Map<String, data definition>> Or
capability type: {List<capability data definition>}
Map<String, Map<String, List<data definition>>>
For this cases defined classes like
public class ListDataDefinition<T extends ToscaDataDefinition> extends ToscaDataDefinition {
protected List<T> listToscaDataDefinition;
public class MapDataDefinition <T extends ToscaDataDefinition> extends ToscaDataDefinition {
protected Map<String, T > mapToscaDataDefinition;
Using the following classes we can create any data structure for Tosca.
Examples : MapPropertiesDataDefinition, MapListCapabilityDataDefinition, MapGroupsDataDefinition

11. Add member to resource - cont
2. Add members to BL model and graph model
BL level Model level
All data added to components must be grouped by common type ( artifacts, properties, interfaces, groups, etc.). The data will be saved as json string into separate vertex on Titan.

12. Add member to resource - cont
Optional:
3. Add support to creation to TopologyTemplateOperation/NodeTypeOperation
Mandatory:
4. Add support to delete to TopologyTemplateOperation/NodeTypeOperation
status = titanDao.disassociateAndDeleteLast(toscaElementVertex, Direction.OUT, EdgeLabelEnum.MY_NEW_TYPE);
5. Add new Flag to ComponentParametersView ( used as filter for fetching data)
6. Add support get to TopologyTemplateOperation/NodeTypeOperation according to flag
7. Add convertation to ModelConverter from BL model to ToscaElement and from ToscaElement to BL model

13. Tosca inheritance Data type inheritance
This concept is relevant for all data types: groups, capability, policies, etc.
TitanGenericDao is used for these types.
tosca.datatypes.network.NetworkInfo:
derived_from: tosca.datatypes.Root
properties:
network_name:
type: string
network_id:
addresses:
type: list
entry_schema:
org.openecomp.datatypes.heat.novaServer.network.AddressInfo:
derived_from: tosca.datatypes.network.NetworkInfo
description: Network addresses with corresponding port id
port_id:
description: Port id
required: false
status: SUPPORTED

14. Node type inheritance tosca.nodes.network.Port:
derived_from: tosca.nodes.Root
org.openecomp.resource.cp.nodes.network.Port:
derived_from: tosca.nodes.network.Port

15. Vertex data model

17. Delete entities
No delete properties in data types ( groups, capability type, policy, etc.). Reason – no versioning for data types
Only adding of new properties is supported
No change type of property ( like delete)
Properties can be deleted in node types – exist versioning
No delete “closed” resources. Only undo checkout operation.
All non certified versions will be deleted automatically :
After certification all resources between 2 certified versions will be marked as deleted. Exist special task that will delete all marked as deleted components if no usage it as instance in another component.

18. Base Operation API
All operations on Titan model are in Operation classes
Generic API in BaseOpearion
addToscaDataToToscaElement
Add data to json(map) by given key/s

19. updateToscaDataDeepElementOfToscaElement
Example : Add group object to json
group_name : { GroupDataDefinition}
addToscaDataToToscaElement(component.getUniqueId(), EdgeLabelEnum.GROUPS, VertexTypeEnum.GROUPS, currentGroup, JsonPresentationFields.NAME);
updateToscaDataDeepElementOfToscaElement
Update element in more that 1 level hierarhy in json
Example: update property on component instance. The data is representing by next json
Instance id :{
property name :{ PropertyDataDefinition} }
List<String> pathKeys = new ArrayList<>();
pathKeys.add(componentInstanceId);
updateToscaDataDeepElementsOfToscaElement(containerComponent.getUniqueId(), EdgeLabelEnum.INST_PROPERTIES, VertexTypeEnum.INST_PROPERTIES, properties, pathKeys, JsonPresentationFields.NAME);

20. addToscaDataDeepElementsBlockToToscaElement
Add entry under main key in json.
Add all instance properties under instance .
addToscaDataDeepElementsBlockToToscaElement(containerId, EdgeLabelEnum.INST_PROPERTIES, VertexTypeEnum.INST_PROPERTIES, properties, componentInstanceId);
BaseOperation can handle all options of update vertex data.
Example : More than one resource versions have same data:
BaseOperation will detect this
and the relevant vertex
will be cloned