Skip to end of metadata
Go to start of metadata

In iteraplan 6.1 the Metamodel saw a huge extension. All data APIs, export/import formats etc. will of course reflect these changes. Existing scripts/REST calls/Excel sheets etc. from versions before 6.1 might have to be adapted for iteraplan 6.1. 

See here for all details of the extended Metamodel: Metamodel in 6.1

In general

There are two main changes in the iteraplan Metamodel:

  • All relations between Building Block types are now attributable. This does not aply to self-relations like parent-child, which stay non-attributable. Before release 6.1, only three relations wre attributable, e.g. the Infrastructure Element to Information System Relation.
    So now with 6.1 all relations have to be treated like the Infrastructure Element to Information System relation.
  • The Interface Building Block Type has been overhauled. Internal technical names related to the Interface (now called Information Flow) changed.

Looking at the internal technical names:

 Before 6.1Starting with 6.1
Example for a Relation
(iteraQL syntax)
BusinessFunction/projects

BusinessFunction/projectAssociations/project

Information Flow
to Business Object
(iteraQL syntax)
InformationsystemInterface/InformationFlows/businessObjectInformationFlow/businessObjectAssociations/businessObject

The following paragraphs give somes examples and detail the changes for different formats.

Information Flow diagram

The filter option in the Node Filter for the relation "Assigned Interfaces" is now called "Information Flow 1/ 2". In the Edge Filter, the Direction attribute of transported Business Objects moved from the Information Flow attributes to Transported Business Objects attributes.

The Interface Direction, formerly located in Assigned Interface attributes, is now located in the Information Flow attributes. 

Excel Export / Import

The overall structure of the Excel import/export file itself has not changed. Data is still exported and imported in tabular form, spread across several sheets in the excel file.

Starting with 6.1, all relations between different Building Block Types are attributable. Because of this, all relations are now placed on their own sheet in the Excel file. Also internal technical names related to the Interface (now called Information Flow) changed.

Excel sheets from versions before 6.1 are not compatible with iteraplan 6.1. Should you have old Excel files to import, we generally recommend not to adapt these files (e.g. change the internal, technical names in the hidden rows). Instead of that consider exporting an empty file (choose Format 'Excel' & Model 'Metamodel' on the Export page) and then copy the data to the new file.

Graphics Reactor

Relations from one element to another are now realised via a relation object.

 Before 6.1Starting with 6.1
snippets from iteraplan.xmi
<contents xsi:type="iteraplan:BusinessProcess" name="Marketing" id="35"
  position="0" Strategic_32_value="8.00" businessDomains="#55" children="#42 #43"
  parent="#23" projects="#94 #103">
  <Accountability>alice</Accountability>
</contents>

<contents xsi:type="iteraplan:BusinessProcess" name="Marketing" id="59"
  position="0" Strategic_32_value="8.00" children="#66 #69" parent="#52"
  projectAssociations="#1345" businessDomainAssociations="#729">
    <Accountability>alice</Accountability>
</contents>  
 
<contents xsi:type="iteraplan:Proj2BpAssociation" id="1345"
  businessProcess="#59" project="#233"/>
snippet from iteraplan.ecore
<eClassifiers xsi:type="ecore:EClass" name="BusinessDomain">
 
<eStructuralFeatures xsi:type="ecore:EReference" name="businessFunctions"
  unique="false" upperBound="2147483647" eType="#//BusinessFunction"
  eOpposite="#//BusinessFunction/businessDomains">
  </eStructuralFeatures>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="BusinessDomain">
 
<eStructuralFeatures xsi:type="ecore:EReference" name="businessFunctionAssociations"
   unique="false" upperBound="2147483647" eType="#//Bf2BdAssociation"
   eOpposite="#//Bf2BdAssociation/businessDomain">
   </eStructuralFeatures>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Bf2BdAssociation">
 
<eStructuralFeatures xsi:type="ecore:EReference" name="businessFunction"
  unique="false" lowerBound="1" eType="#//BusinessFunction"
  eOpposite="#//BusinessFunction/businessDomainAssociations">
  </eStructuralFeatures>
</eClassifiers>

Plugin API

In your Plugin API Scripts you should update the persistent names of Building Block Types and connections. 
Make sure you change the names of the connections according to the new Naming conventions for Building Blocks and Relations.
Before 6.1Starting with 6.1
connect IS-TC
someInformationSystem.connect(someTechnicalComponent, 
"technicalComponentReleases");


connect IS-TC
var relationObject = api.datamodel.create('Is2TcAssociation');
relationObject.connect(someInformationSystem, "informationSystem");
relationObject.connect(someTechnicalComponent, "technicalComponent");

disconnect BO-BF
someBusinessObject.disconnect(someBusinessFunction, 
"businessFunctions")

disconnect BO-BF
var allBMs = api.datamodel.findByType('BusinessMapping');
var bfId = someBusinessFunction.getId();
var boId = someBusinessObject.getId();

for (var index=0; index < allBMs.length; index++) {
        if(allBMs[index].getRelatedObject('businessFunction') &&
            allBMs[index].getRelatedObject('businessFunction').getId()== bfId &&
            allBMs[index].getRelatedObject('businessObject') &&
            allBMs[index].getRelatedObject('businessObject').getId()== boId &&
            !allBMs[index].getRelatedObject('informationSystem')&&
            !allBMs[index].getRelatedObject('businessUnit')&&
            !allBMs[index].getRelatedObject('businessProcess')&&
            !allBMs[index].getRelatedObject('product') &&
            !allBMs[index].getRelatedObject('itService')){
                allBMs[index].remove();
        }
}



Historization data

The format of the historization data returned via the REST API has not changed. But internal technical name changes and the introduction of attributable relations are reflected, of course.

Before 6.1
(non attributable relation)
Starting with 6.1
(attributable relation)
{
   "history":[
      {
         "author":"system",
         "time":"2017-12-17 19:27:46",
         "changetype":"UPDATE",
         "changes":[
            {
               "featureName":"informationSystemReleases",
               "featureType":"RELATIONSHIP",
               "isMultiple":true,
               "addedValue":[
                  "BI # 1.0"
               ]
            }
         ]
      }
   ]
}
{
   "history":[
      {
         "author":"system",
         "time":"2017-12-17 19:38:57",
         "changetype":"UPDATE",
         "changes":[
            {
               "relation":"informationSystemAssociations/informationSystem",
               "changesOfRelations":[
                  {
                     "nameOfRelatedBB":"BI # 1.0",
                     "changetype":"INSERT",
                     "changes":[

                     ]
                  }
               ]
            }
         ]
      }
   ]
}

REST API

The introduction of attributable relations has an effect on the format of the JSON snippets in REST requests. See here for the full list of technical names of all relations: Naming conventions for Building Blocks and Relations

Before 6.1
(non attributable relation to project)
Starting with 6.1
(attributable relation to project)
POST to api/element/InformationSystem
{
    "name" : ["InformationSystem1"],
    "typeOfStatus" : ["CURRENT"],
    "successors" : [{"id": "1"}],
    "projects": [{"id": "3"}]
}
POST to api/element/InformationSystem
{
    "name" : ["InformationSystem1"],
    "typeOfStatus" : ["CURRENT"],
    "successors" : [{"id": "1"}],
}
POST to api/element/Is2ProjAssociation
{
   "informationSystem": [{"id": "123"}],
   "project": [{"id": "3"}]
}

Technical names / iteraQL

As of 6.1 some relations in iteraQL have new technical names. You can find all relations and their iteraQL names in Naming conventions for Building Blocks and Relations.

Especially relations between Information System Interfaces (now called Information Flow) and Information System Releases (now called Information Systems) have changed.

The following list shows changes in relations of Information System and Information Flow in version 6.1.

Building Blocktechnical name of relation
before 6.1
technical name of relation
starting with 6.1

Formerly: InformationSystemInterface
now: InformationFlow

informationFlows
/informationSystemRelease1

informationSystem1Association
/informationSystem
informationFlows
/informationSystemRelease2
 informationSystem2Association
/informationSystem
technicalComponentReleasestechnicalComponentAssociations
/technicalComponent
-architecturalDomainAssociations
/architecturalDomain
-businessDomainAssociations
/businessDomain
InformationFlow
/businessObject
businessObjectAssociations
/businessObject
-projectAssociations
/project
-informationSystemDomainAssociations
/informationSystemDomain

Formerly: InformationSystemRelease

Now: InformationSystem

 

 

 










businessObjectAssociations
/businessObject

businessMappings
/businessObject

businessFunctions

businessMappings
/businessFunction

informationSystemDomains 

informationSystemDomainAssociations
/informationSystemDomain

informationFlows1
/informationSystemInterface

informationFlow1Associations
/informationFlow

informationFlows1
/informationSystemRelease2

/informationFlow1Associations/informationFlow/
informationSystem2Association/informationSystem

informationFlows2
/informationSystemInterface

informationFlow2Associations
/informationFlow

informationFlows2
/informationSystemRelease1 

/informationFlow2Associations/informationFlow/
informationSystem1Association/informationSystem
itServices

businessMappings
/itService

projects

projectAssociations
/project

technicalComponentReleases

technicalComponentAssociations
/technicalComponent

  • No labels