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.
- Components are contained within Projects; each Component represents a part of the system specified by the Project, e.g. a subsystem, logical object or physical object.
- Components contain Configurations, variants of the Component comprised of variants of the artifacts that make up that component. These Configurations may be Streams or Baselines.
- Streams are evolving Configurations. Project members post changes to the stream on an ongoing basis.
- Baselines are static Configurations, capturing the Component configuration at a particular moment in time that the team wishes to preserve.
- Streams and Baselines contain specific versions of Artifacts such as Folders, Requirements, and other DNG element types.
- Components, Streams, and Baselines are all classified as Artifacts in the Syndeia data model. See the API Overview accessible from the Syndeia Cloud Web Browser Help menu for more information.
The Syndeia_Cloud_3.5 DOORS-NG_CM_Enabled_Projects notebook illustrates requests and responses for eight major questions.
- What projects are in a DOORS-NG repository?
- What components are in a DOORS-NG project?
- What streams are in a DNG component?
- What folders and artifacts are in a DOORS-NG stream?
- What are the contents of a folder in a specific stream and component?
- What baselines are in a DNG component?
- How do I find a DOORS-NG artifact by ID in a specific stream and component?
- What is a DOORS-NG artifact connected to (in other models)?
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).
Getting Started
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.
Parts 1 and 2
As in the previous notebooks, the initial cells are devoted to
- Importing Python libraries, including the Syndeia Cloud Python language client,
- Authenticating into Syndeia Cloud through its own REST API, and
- Retrieving a list of repositories (DOORS-NG repositories in this example) that this instance of Syndeia Cloud is set up to access.
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.
What DOORS Projects are in a Repository?
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.
What DNG Components are in a Project?
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.
What Streams are in a Component?
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.
What Folders and Artifacts are in a Stream?
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.
Get the contents of folders in a specific stream of a specific component
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.
What Baselines are in a Component?
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.
Search DNG Artifacts by ID
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.
What is a DNG Artifact connected to (in other models)?
Part 5 is divided into three subsections:
- In Step 5.1, we find the stream-specific ID of a DOORS NG artifact in a specific stream of a specific container. The artifact’s configuration-independent ID or external key, “378” in this example, applies to the artifact independent of which stream or baseline it appears in, but we need its stream-specific ID.
- In Step 5.2, we get the child artifacts belonging to the artifact in Step 5.1.
- In Step 5.3, we iterate through the list of child requirements and make a graph query to Syndeia Cloud searching for inter-model connections to or from each.
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.
Conclusions
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
Download TechNote(s).
Click here to download our Technotes.
Next in this series
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.
- Part 1 – Introducing the Syndeia API
- Part 2 – Hello Syndeia Cloud Notebook
- Part 3 – Syndeia Cloud 3.5 JIRA Notebook
- Part 4 – Syndeia Cloud 3.5 Analytics Notebook
- Part 5 – Syndeia Cloud 3.5 Jama Notebook
- Part 6 – Syndeia Cloud 3.5 DOORS-NG Regular Projects Notebook
- Part 7– This part
- Part 8– Syndeia Cloud 3.5 TestRail Notebook
Contributions by
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).