The RayQC integration into RayFlow is solved as a tool utilization. Tools may be configured for any RayFlow process phase, and are used to trigger external functionality which will be applied on the package object from RayFlow. This RayQC tool integration is usually something that is defined for the QA activity within the packaging phase, or user acceptance checks within the UAT phase. RayFlow is absolutely free for additional tool integrations, but according to the Best Practice EALM workflow Raynet suggests that those two phases benefit most from a direct RayQC tool integration.
The upcoming procedure descriptions start from a RayFlow package data object. A user has to be logged on to a RayFlow client and access the required workflow phase in order to successfully trigger this kind of RayQC interaction. From the overview of packages that currently reside in the workflow phase, the user has to right-click the package within the RayFlow user interface in order to display the tools available for further processing of the package object.
Initiate RayQC Checklist Evaluation
From the list of available tools presented in the context menu, users have to pick "Evaluate with RayQC" to actually initialize a RayQC session with fitting RayFlow connection and package object reference parameter values.
Usually the tool trigger opens RayQC with a specific checklist template or project opened in the Checklist Viewer mode, ready for immediate evaluation activity. The checklist is not transferred from RayFlow to RayQC, but is known in RayFlow by its path. This path information is sent to RayQC as part of the command executed when the RayQC tool call is done.
|
Be aware: The checklist and all related resources have to be available for the user who launches RayQC as a tool via RayFlow. The required access rights, and most likely network shares as well, have to be prepared in advance and aligned between all applications and user profiles that are active parts of the RaySuite system environment. |
If there are checklist elements which have been configured to operate as RayFlow parameter containers, they are already filled with the properties of the related data object when the checklist is opened this way. The tool triggered RayQC session has automatically established a connection to the RayFlow database, in order to retrieve object properties if required. The usual identifier used for this data exchange is the unique package id property from RayFlow. It has to be part of the command executed when the RayQC tool call is done.
These two steps are the core of the evaluation initialization via RayFlow: Opening a RayQC instance with a data link to the RayFlow package object and a predefined checklist that is ready for evaluation.
Initiate Automated RayQC Report Generation
This method takes the procedure described above to another level of convenience, efficiency, and result quality: When an automated report generation is triggered by a RayQC tool integration, the procedure goes beyond opening a RayQC instance with a data link to the RayFlow package object and a predefined checklist: it automatically runs all plug-in integrations which are configured within the checklist template, generates a report file and sends it back to the file repository of the package object within the RayFlow database.
However, there are some requirements regarding design limitations for automated checklists:
•RayQC can only launch plug-ins in this automated scope if they do not require user interaction.
For example:
It is not possible to execute the FileOpenDialog function from the internal File plug-in, because it needs manual response from a user: the selection of a file within the opened dialog window.
RayQC is capable of recognizing these interactive functions for internal plug-ins. However, if a custom plug-in requires user interaction, RayQC does not have enough information to recognize this for auto-reports; and gives a warning when Run All is executed for a checklist with non-leading interactive plug-ins. Therefore, it is part of the checklist author's responsibility to prepare interaction free checklists for automated execution purposes.
•When the checklist has been processed, RayQC creates a report, no matter if the list is finished or not.
There may be checklist elements which require manual input (user interaction). These element results will not be provided in the scope of an automated run. Therefore, a checklist that contains such elements can never terminate as PASSED or FAILED.
•During the data transfer phases between RayFlow and RayQC there has to be a stable connection to the RayFlow webservice for data exchange. If this connection gets lost, the process cannot be completed automatically and has to be finished manually.
•Automated report generation procedures may only run on evaluation systems that are already prepared for the test cases executed by the specific checklist. Since RayFlow simply launches a local checklist and receives results as a report, there is no possibility to adjust local settings, copy resources, or the like. These tasks have to be prepared in advance.
RayQC creates a local copy of the checklist report that has been generated for auto-upload. Therefore, if the report file somehow gets damaged during the data transfer phase, the information it contained is not lost, but retrievable from the %appdata% folder of the current RayQC user on the local evaluation machine.