FAQ about the QA scanner

[Yori]

Frequently Asked Questions

This post will go into frequently encountered scenario’s and will help you to get your components to the Beta status.

This post will focus on solving the findings of the QA-scanner. For more information about how the QA-scanner works, or how to scan a component or model see how to use the QA scanner.

Product issues

Some administrative checks are performed on the PI’s that have been created or modified between the last revision with beta status or higher and the scanned revision. Note that messages on revisions higher than the scanned revision are not taken into account. For example, you have created a component with 3 revisions each revision is linked to the same PI, after finishing your work you have placed a release note on revision 3. If you are to run the QA-scanner on revision 2 it will tell you there is no release note as it only checks messages linked to revision 1 and 2. To solve this make sure to always scan the newest revision.

Missing releasenotes

This will probably be the most common message.

To fix this you can follow these steps:

1. Click on the PI title, this opens the NNetwork application and opens the respective PI record. (log in with your architect account, if not yet logged in it will take you to the metro, after logging in close NNetwork and click the link again to be redirected properly).
2. On the bottom right you can add a new message. Pick the message template “Releasenote” *.
3. Use the template to describe the feature / bugfix of this PI.
4. Select the revision number this releasenote applies to. You can find this in the QA scanner screen, the message will tell you what revision is missing the release note. As a general rule the latest revision of a PI should always have a release note.
   
   
5. Save the message.

*In case it’s a very small change or a PI just to produce a process component or feature, you can also use the template “Release note fo produce” or change the message type to “PI has no user impact”, “PI has no user impact” is treated equally in the QA-scanner.

Unlinked revisions

When seeing “The following revisions are unlinked:” with one or multiple revisionnumbers behind it, this means that there are one or more revisions that are not linked to a single PI. This behaviour can occur when your architect is not correctly linked to the issue tracker, resulting in a save without a PI.

This issue can be solved in two ways:

Link the revision to an existing PI.

1. Open NNetwork and go to the overview of PI’s.
2. Choose a PI for the scanned component which concerns the change done in the unlinked revision.
3. Add a message of type note and link the mentioned revision. In this note add the workitem message you would normally have written through the issue tracker within the architect detailing the change.

Link the revision to a new PI.

1. Open NNetwork and go to the overview of PI’s
2. Add a new PI and link it to the scanned component. Give it a name detailing the change.
3. Add a message of type note and link it to the mentioned revision. In this note add the workitem message you would normally have written through the issue tracker within the architect detailing the change.

Translations

The translations check tells you which languages were available in the last beta revision. In the following example we see that the previous beta revision had english and dutch translations. In the scanned revision not all elements have a dutch translation and thus the dutch translations are not retained fully. To solve this issue open the component and add the missing translations.

Composability

Component composability

Before we start with component composability note that we are currently looking into improving the algorithm and reducing the number of times a composition cannot be found while one is possible.

The “composable with at least CTP” versions is likely the most difficult error to solve. It is important to understand how the QA scanner works in order to tackle this error. When checking the component composability the QA scanner adds the scanned revision to an empty cart. Most components consume multiple elements. Since each consume also requires a produce, the component can’t be composed on its own. The QA scanner algorithm will try to add all required components (initially of status Beta or higher, and later of status CTP or higher) until no more consumes are left unsolved (and no duplicate produces occur). The algorithm branches out and tries several options before going back and trying another route. Routes with few added consumes are preferred. Eventually the algorithm stops if it cannot come up with a solution within a reasonable amount of attempts. This is what can be seen below “Unable to solve the cart, cannot solve the following requirement(s):”. This error does not mean that the consume itself has no producer or is wrong, but merely that it cannot find a composition in which this element is only produced once without causing additional consumes that cannot be solved. Note that while the algorithm attempts to solve the cart, it will likely fail on many different consumes at different attempts. It only shows one of these cases, with the least amount of unsolved consumes. This may not always be the optimal solution to show but is the best way of telling how ‘close’ the algorithm was to a solution.

This entire process can be done by hand as well. When clicking the “view analyze page” of the “Composable with at least CTP versions” you get to a page where you can find the following important information for trying to find a solution:

Look at the “consumed in running cart by:” first. Is this a component that does not match with the industry that the scanned component is used for, the issue is that the QA scanner algorithm may have taken a wrong turn and got stuck in it.

The next valuable piece of information is the “produced by” where the scanner suggests potential solutions like:

• Get a component revision from NB to CTP
• Duplicate produces are causing an issue and might not be required. Proceed with caution here!
• The amount of consumes in a component is very high and potentially still has a lot of unused consumes causing issues.

Lastly the “Cart actions” these allow you to see how the algorithm started and ended. For doing this you can follow these steps:

1. Click on the copy input or output integration string.
2. Open the composer and log in.
3. Click on Dashboard.
4. Paste the integration string in the integration string text area
5. Click on Load(string).

This creates a new cart with the components and revisions for the start and end of the QA scan respectively and may provide information over where the scan has taken a turn you did not expect.

Reference architecture

Use of draft elements

It is important to create a change request for newly produced concepts, features, enums and processes, see How to create a change request. Note that the QA-scanner displays the initial name of the element, this name is not updated when the name in the appserver changes. This is a known bug and will be fixed in the future. After creating a change request, draft elements still need to be reviewed by the Reference Architecture Review Board. This is a manual check to determine if the produces that are requested are valid, and may take some time. If you know for certain the elements have been submitted you might have to wait up to 10 working days and rescan at a later time. If you are unsure if the draft elements have been submitted, perform the following steps to check.

1. Open the Appserver
2. Create a new change request.
3. Look for the element based on GUID in the respective grid (concepts, features, enums or processes). If the element shows up this means it is not yet in any change request. Follow the instructions in How to create a change request and submit when done, in this case you may skip the remaining steps. If the element does not show up it means it is already in a change request. If possible (due to rights) it is still relevant to check if this change request has been submitted and does not have any remarks from the Reference Architecture Review Board. Go to step 4 to do so.
4. Open the expression debugger and run the following expression after replacing the GUID. { referencearchitecturechangerequestitems, change_request, boolean:or([ concept.uuid.equals(parent), feature.uuid.equals(parent), enumeration.uuid.equals(parent), process.uuid.equals(parent)]), this.id.asc } with your GUID in the context:
   
   
5. If you have rights to the change request you will see the id in the result. Use this id to open the corresponding change request and check its status and notes (notes by submitter are currently used by the Review Board to place a response if there are issues with the request).

Deprecated elements.

Often when an element becomes deprecated it is either no longer used or has a replacement which has more functionality.

First, check whether the consume is actively used.
– If it is not, simply remove it.
– If it is, check whether a replacement is available:
• If a replacement exists, follow step 1.1.
• If no replacement is available, continue with step 1.2.

1. Replacement available
   1. Consume the replacement inside of the scanned component
   2. Find all locations where the deprecated element is used and replace them with the replacement consumed at step 1.
   3. Remove the Deprecated element.
   4. Double check that no errors occur in locations that might have been missed in step 2.
   5. Save the component
   6. Rescan the component
2. No replacement available
   1. Try to find an alternative method to reach the same goal. If no alternative can be found, ask a Novulo developer.
   2. When an alternative has been implemented remove the old consume.
   3. Save the component.
   4. Rescan the component.

Rejected elements

An element may be rejected in case it already exists or if it is not logical. In this case the member of the architect reference board will most of the time contact the person who has submitted the element before setting it to rejected in order to ensure a solution is discussed.

If a rejected element is present in the scanned component see if a replacement is available and modify the component accordingly.

Dependancies on CTP components

In some cases a component is dependant on other components. In cases like these a component may require other components to be ready for a beta status at the same time. In the example below M9294 r27 has been scanned and is ready to become beta, however 2 other components that M9294 relies on still have to become beta. In such a case solve the issues in the other component first (if you worked on it), otherwise you may have to wait for the person who did the work to get that component ready for a beta status as well.

Architect issues

All components should not have any issues according to the problems tracker built in the Architect.

1. Open the component in the latest available stable Architect version (this is the default setting of the Architect launcher).
2. Fix all issues shown in the problems tracker. The end result should be: Problems (0/0/1/0).
   Note: there will always be an info message saying “Cannot generate model, because it consumes x concepts and y process components.”.

Unexpected issues

In this part we will cover a few issues that may occur which are caused by the qa-scanner not working properly. These cannot be solved by you and should be reported via a SR.

Status: failure

When the QA-scanner returns a status: failure, the scan has not been performed properly, this is likely caused by the queing process. If you encounter this issue please make a service request and try scanning again.

This post will be updated with more examples