Model synchronization

To control the migration of model elements, the following YAML file serves as a configuration for the capella2polarion service. In this file, you can specify the layer, class types and attributes for matching Capella model elements. Additionally you have the control of adding relationships with the links key. Underneath the links key use attributes on the matched capellambse model object. Make sure that the attribute name is correct, you can use capellambse’s documentation for that.

Generic

"*": # All layers
  "*": # All class types
    links: # Specify workitem links
      - parent
      - description_reference
    serializer:
      add_attributes:
        - capella_attr: layer
          polarion_id: layer
  Class:
    serializer:
      add_tree_diagram:
        render_params:
          depth: 1
    links:
      - state_machines
  Diagram:
    links:
      - diagram_elements
  Constraint:
    serializer: linked_text_as_description
  Scenario:
    serializer: include_pre_and_post_condition

The “star” section is a general configuration where you can set links to be migrated for all class types. For example, parent and description_reference are links that will be applied to all specified class types. Since Class is a common class type that exists in all layers, links specific to Class can be specified here to avoid duplication. This will be merged into layer specific configuration for Class if there is any.

Serializers

  OperationalCapability:
    serializer: include_pre_and_post_condition

With serializer you can control which function is called to render the capella2polarion.data_models.CapellaWorkItem. There is a generic serializer including title (name), description and requirement types, taken per default. You may also define multiple serializers by providing a list of serializers in the configs. These will be called in the order provided in the list. Some serializers also support additional configuration. This can be done by providing a dictionary of serializers with the serializer as key and the configuration of the serializer as value. For example Class using the add_tree_diagram serializer:

  Class:
    serializer:
      add_tree_diagram:
        render_params:
          depth: 1

or SystemFunction with the add_context_diagram serializer using filters:

    serializer:
      add_context_diagram:
        filters:
          - EX_ITEMS_OR_EXCH # functional exchange or exchange item name

Jinja as Description

The add_jinja_as_description serializer allows you to completely replace the default description content with the output of a rendered Jinja2 template. This provides maximum flexibility for customizing the main content area of your Work Items enabling HTML structures like tables, lists and more in it.

You need to specify the path to the template file. Optionally, you can also provide the folder containing the template and any parameters required by the template for rendering.

serializer:
  add_jinja_as_description:
    template_folder: path/to/your/templates
    template_path: description_template.html.j2
    render_parameters:
      custom_var: "some_value"
      another_param: true

Jinja Fields

The add_jinja_fields serializer enables populating specific custom fields in Polarion with content generated from Jinja2 templates. This is useful for adding structured, dynamically generated information to Work Items beyond the standard description or splitting HTML structures from the description to a dedicated custom field.

For each custom field provide its Polarion ID as a key. The value should be a dictionary specifying the template_path, and optionally the template_folder and any render_parameters needed by that template.

serializer:
  add_jinja_fields:
    field_id:
      template_folder: folder/path
      template_path: template.html.j2
      render_parameters:
        key: "value"
    field_id_1:
      template_folder: folder/path
      template_path: template_1.html.j2

If a serializer supports additional parameters this will be documented in the supported capella serializers table in Model synchronization.

Different capella type and polarion type ID

  FunctionalExchange:
    polarion_type: operationalInteraction

Sometimes capellambse class types are not the same in Polarion. In order to handle this case you can use the polarion_type key to map capellambse types to the desired Polarion type.

pa:
  PhysicalComponent:
    - links:
        - allocated_functions
      serializer:
        add_attributes:
          - capella_attr: nature
            polarion_id: nature
    - is_actor: false
      nature: UNSET
      polarion_type: physicalComponent
    - is_actor: false
      nature: NODE
      polarion_type: physicalComponentNode
    - is_actor: false
      nature: BEHAVIOR
      polarion_type: physicalComponentBehavior
    - is_actor: true
      nature: NODE
      polarion_type: physicalActorNode
    - is_actor: true
      nature: BEHAVIOR
      polarion_type: physicalActorBehavior

For the PhysicalComponent you can see this in extreme action, where based on the different permutation of the attributes actor and nature different Polarion types are used. In capellambse however this is just a PhysicalComponent. Combining this with links is possible too. You can configure a generic config and for each specific config you can also add a links section. Both will be merged.