In Part 6 of this series, we described Syndeia Cloud REST API calls to non-Configuration-Managed (non-CM or regular) DOORS NextGen (DNG) projects. DNG projects that are CM-enabled require users to navigate through several additional levels of Components, Streams, and Baselines to access all the data in the project.
The Syndeia_Cloud_3.5 DOORS-NG_CM_Enabled_Projects notebook illustrates requests and responses for eight major questions.
For each section, we will identify the question being asked and what the results look like. More detail about the API method/Python code patterns used to make these queries are described in the accompanying TechNote(s).
All Syndeia documentation can be accessed most easily through the Help icon on the Syndeia Web Dashboard once Syndeia Cloud has been installed. In terms of thinking about these queries, it may be especially helpful to review the Syndeia data model under API – Overview. Intercax periodically offers on-line live training classes that provide a comprehensive review of all things Syndeia. Click here to check it out.
As in the previous notebooks, the initial cells are devoted to
The results for this list are shown in Figure 1. This query was made to the Syndeia database, not the DOORS repository, but we will need a DOORS Repository Key, REPO11 in this example for DNG 7.0.2 @ Intercax, in our next DOORS-specific requests. For more information on the Syndeia-related Python code in this section, see the TechNote, “Queries to Syndeia Cloud Database”. The link is shared below.
The cells labelled Step 2.2 asks, “What DOORS-NG projects are contained in the DNG 7.0.2 @ Intercax repository?” Before this request could be passed to DOORS, the user is asked at run-time to enter their DNG password, which is required along with their username for all requests. For the request, we used the DOORSNGApi class with the doors_sign_in() method followed by the get_doors_containers() method. The results are tabulated as in Figure 2. This report shows only the project name, but project keys (IDs) are also returned with the response and will be used for later requests. For more information on the Syndeia-related Python code in this section, see the TechNote, “DOORS NG Authentication and Projects”. The link is shared below.
In Step 3.1, we ask, what are the Components in a specific DNG project, “JasClm702_CmEnabled_RmProject”?. The results are tabulated in Figure 3, showing each artifact with name and ID.
Step 3.1 uses the get_doors_artifacts() method with the optional parameter container_external_key to identify the DOORS project. We have added one more parameter type_external_key to restrict the results returned to Components only. For more information on the Syndeia-related Python code in this and following sections, see the TechNote, “Navigating DOORS-NG Components, Streams and Baselines”. Link shared below.
In Step 3.2, the notebook searches for Streams in “Second Component” using the get_doors_artifacts() method with the optional parameters other_component to identify the Component and type_external_key to restrict the results returned to Streams only. Figure 4 shows the results. For more information on the Syndeia-related Python code in this and following sections, see the TechNote, “Navigating DOORS-NG Components, Streams and Baselines”. Link shared below.
The response shown in Figure 5 for Step 3.3 digs one level deeper, using parameter other_configuration set to "FirstStreamOffSecondComponentInitialStream". This stream’s key was retrieved in the previous section.
The next example of the get_doors_artifacts() method is shown in Figure 6. The request specifies a particular folder by name, “01 Requirements”, retrieves its key from results in Figure 5, and uses the optional parameter other_folder.
In the last four sections, we have progressively drilled down from Projects to Components to Streams to Folders to the contents of a Folder. The same progression can be done for Baselines instead of Streams, but we only carry out the Components to Baselines step in this example in the next section.
In Step 3.5, the notebook searches for Baselines in “Second Component” using the get_doors_artifacts() method with the optional parameters other_component to identify the Component and type_external_key to restrict the results returned to Baselines only. Figure 7 shows the results.
In Part 4, Syndeia uses the get_doors_artifact_by_external_key() function to search for a specific artifact by its external (DOORS-based) key and the key of its Configuration (Stream or Baseline). The notebook example prints out the name and url of the artifact.
Part 5 is divided into three subsections:
Step 5.1 identifies a component and stream by name and an artifact by external key. It sequentially checks for components of the specified name in the project, then for streams of specified name in the component, and finally for artifacts of the specified external key in that stream. For the last, it uses the get_doors_artifact_by_external_key() method with the other_configuration optional parameter to identify the stream. If all checks are successful, it prints out a message indicating success.
In Figure 8, we display a list of the artifacts contained in the requirement collection (ID=”378”) specified in 5.1. We use the get_doors_artifacts() method with the other_configuration and other_collection optional parameters to identify the stream and parent artifact, respectively.
In Figure 9, we display a list of the Syndeia inter-model relations in the Syndeia container (digital thread project) “MBSB01” to or from the DNG artifacts from the list displayed in Figure 8. Unlike the previous requests described in this post, this request is directed to the Syndeia Cloud database, not the DOORS NG repository, and it is made in the form of a Gremlin language query.
The query iterates through the list of artifacts and prints the number of inter-model connections for each artifact. In this example, only five of these have inter-model connections. Those appear in the table at the bottom of Figure 9 with the relation id (Syndeia key) and the source and target artifacts. Each of the artifacts is represented by a link to the element in its native repository, DOORS NG and JIRA respectively in this example.
In this Jupyter notebook, we have extended our explorations of DOORS NextGen repositories to Components, Baselines, and Streams in a CM (Configuration-Managed) DOORS Project.
Jupyter Notebook: Syndeia_Cloud_3.5_DOORS-NG_CM_Enabled_Projects
Click here to download our Technotes.
The next set of posts in this series will use Jupyter notebooks as the primary means for demonstrating the Syndeia API and will focus on the following topics.
The notebook was created by Dr. Manas Bajaj, Chief Systems Officer at Intercax, who leads product research and development. He was a contributor to the SysML (Systems Modeling Language) 1.0 open standard and leads the SysML v2 API and Services standards development as part of the SysML v2 Submission Team (SST).
