4.5.3.4. Workflow 2 - Cables sent to IRM from Linkware Live
This topic gives a step-by-step explanation of this workflow:
A Linkware Live project contains test results of some existing physical cables that are not currently defined in IRM. The user wants representations of these cables to be created in IRM, and those existing test results to be uploaded to IRM.
The Linkware Integration Service (LIS) becomes aware that there is a new Project in Linkware Live with cables and tests that may need to be pushed to IRM. LIS creates a Proxy for the new Project, but it is initially left in an un-monitored state. Neither LIS nor IRM will do anything with the new Project until a user toggles the monitoring for it to ‘on’ .
Activating monitoring is done by selecting the Project in the left panel list and clicking on the Toggle Monitoring button below it. This also changes the Project icon from "pause" to "play" and the color of the Project's name to green.
to 
A monitored Project that has Task Requests that need action from the IRM User side are shown with name label colored in red, as an indication to the user that some action needs to be taken in IRM -
.
TIP: In addition, the user can configure a Trigger Action for the creation of a Task Request, in order to notice the Task Request when created.
Once the new project is monitored, LIS will try to determine whether all of the incoming cables already exist in IRM by matching the Label value (representation of Cable names on Linkware side) against Cable names from IRM. If any Linkware cables are missing, the Task Request flow below is followed for the missing cables.
Essentially, two different kinds of Task Request can be created from a new Project:
-
one for cables that still need to be created in IRM, including their Type Name
-
one for existing cables for which test data needs to be retrieved from Linkware Live
-
LIS addresses the non-existing cables in an “incoming” Task Request object with:
-
Proxy Variety set to Create, which will create the set of objects indicated by Object Names fields in the given Target App
-
Target App set to IRM, which refers to the application (IRM or otherwise) in which this Task Request can be fulfilled by doing something
-
Lifecycle Stage set to "Scheduled"
-
"Applies To Super Category" set to Cable
-
Type Name set to the Linkware cable type name
-
Objects filled out from the list of Linkware Cables
-
LIS addresses existing cables in a Planned Task Request object with:
-
Variety set to Test, which will Test the set of objects indicated by Object Names. For Linkware, we expect to have outgoing Task Requests for technicians to test a set of Cables given in the "objects" field.
-
Target App set to the Linkware Target App
-
Lifecycle Stage set to “Planned”
-
"Applies To Super Categories" set to Generic
-
Objects filled out from the list of existing cables
-
"Is Automated" set to true, indicating the Task Request needs to be handled with user intervention
Note that the second kind of Task Request is normally not viewed by the user, as it requires no user action to be taken.
As already mentioned, in the Cable Test Manager, Projects with a required action pending are shown in red. When the user selects the Project and the list of Task Requests appears, the ones requiring action are also shown in red and have a Lifecycle Stage set to one that requires action (“Scheduled”).
The user then selects a Task Request, which causes the list of Cables to be shown. These are the cables that need to be created in IRM.
Finally, the user selects a cable name and clicks an action button that causes the standard
Create New Cable dialog to be opened with the name field pre-filled with the selected cable name. The user then proceeds to create the Cable.
After all remaining Cables are created, the user clicks the "check" action button -
for the Task Request to set it as Completed, meaning its Lifecycle Stage is set to "Completed". The LIS gets notified by IRM that the IRM Task Request is complete and that therefore all the Cable objects should now exist.
The LIS then goes through the list of completed objects (Cables) in the Task Request and updates Test Results for those Cables. If some Cables don't actually exist (despite the user's claim that all missing Cables have been created), they (obviously) aren't updated. The inclusion of Test Results is done in an idempotent manner, so that it can be executed with partial success and then re-run later without creating duplicate Test Results. In order to avoid that, the Test Date property (which includes a time) is used to determine whether a given Test Result has already been added in IRM, as the same Cable won't have two different Test Results with the exact same time stamp.
