Lab 9: Identify Alerts That Require a Change of State

Transcription

1 Lab 9: Identify Alerts That Require a Change of State In this lab you will work with your consolidated error data stream to work out which alerts require a change of state, and which change of state is required. Remember that the data stream includes the following attributes: The UNIQUEID, which is present in both data streams. The Error Message, which is present in both data streams. The Current Error tag, which, since it is only present in the Current Errors stream, will only be populated for current errors. The currentstate attribute, which, since it is only present in the Old Errors stream, will only be populated for old errors. The first two of these attributes UNIQUEID and Error Message enable you to identify which alert the error record relates to (since these two attributes form the alerts primary key). Between them, the Current Error attribute and the currentstate attribute will tell you whether an alert has been remediated (or has recurred) and whether, therefore, its state needs to be changed. One of the key points to understand is that the only mechanism by which you can change the state of an alert that already exists in Case Management is to republish it. If Case Management receives no information about an alert, its default behavior is simply to persist the alert without changes. This default behavior has three implications for our process: 1. We need to publish an error record to Case Management for every alert that requires a state change, including alerts for errors that have been remediated. 2. This error record should contain information that tells Case Management what state to transition the alert to (for example, transition to Remediated). 3. We do not need to republish errors for existing alerts that do not require a state change, since existing alerts will persist unchanged if we simply do nothing. During this lab you will configure a series of logic checks, and, based on these you will tag each of the consolidated error records with an Error Status. Once published, the Error Status will be used by the reception rules that you set up in this module s first lab to change the state of an alert. The Error Status will depend upon the combination of values found in the currentstate and Current Error attributes. The following table summarizes this: Page 1 of 19

2 currentstate Current Error Error Status Open or Reopened NULL (i.e. not a current error) Remediated Remediated Y Recurred NULL (i.e. not an old error) Y NULL Where the last of these three conditions exists (i.e. the currentstate is NULL, and Current Error is populated with a Y) the Error Status attribute is left NULL. This is because this must be a new error (since it exists now, but did not exist before), and alerts for new errors are automatically created without the aid of reception rules. Since the only purpose of the Error Status is to provide information for reception rules about what to do, in this case the Error Status is not required. Errors that do not meet any of the above criteria must be errors that already exist and do not require a change of state. These can be discarded from the process since, if we do nothing, they will simply be persisted in Case Management without changes which is exactly what we want. Once you have completed this lab, this part of the process will look like this: Add the First Logic Check and Error Status Your first logic check will determine whether you are dealing with an alert that has been remediated. You will be looking for errors that have a currentstate (from the last run) of Opened or Reopened and that are not current errors. Page 2 of 19

3 1. In the Tool Palette, on the right-side of the screen, click to select the Audit family of processors, and then drag a Logic Check processor onto the Canvas. 1. Wire the Consolidated output of the Consolidate processor that you renamed Consolidate the two sets of error data to ensure we only publish one error for each combination of UNIQUEID and Error Message (if we didn't do this, we would get two error records for some errors) to the Logic Check processor s input port. The Logic Check window will open. 2. In the Logic Check window, select the Current Error and currentstate attributes and click to move them to the list of Selected Attributes. Page 3 of 19

4 3. Navigate to the Options tab, and configure it as displayed below: To do this: a) Select the currentstate attribute in the dropdown on the left, select = in the dropdown in the middle and enter Open in the field on the right. b) Click Nest and change the operator to OR. A new set of fields will appear. c) Select the currentstate attribute in the dropdown on the left, select = in the dropdown in the middle and enter Reopened in the field on the right. d) Single-click the OR operator, and click Nest. A new And operator and a new set of fields should appear. e) Select Current Error in the dropdown on the left. Select!= in the dropdown in the middle, and enter Y in the field on the right. f) Ensure that you configuration is exactly as displayed in the screenshot above. Note that the logic here is that the currentstate should be either Open or Reopened and that the Current Error is not equal to Y. 4. Click OK to close the Logic Check window. Page 4 of 19

5 5. On the canvas, double-click the words Logic Check and rename the processor Is this an open or reopened alert that has been remediated? (Logic Check). 6. In the Tool Palette, on the right-side of the screen, click to select the Transformation family of processors, and then drag an Add String Attribute processor onto the Canvas. 7. Wire the Pass output of the Logic Check processor that you renamed Is this an open or reopened alert that has been remediated? (Logic Check) to the Add String Attribute processor s input port. The Add String Attribute window will open. 8. In the Added Output Attributes on the right-side of the window, double-click NewString and rename the added attribute Error Status.1. Page 5 of 19

6 9. Navigate to the Options tab and enter a New Attribute Value of Remediated. 10. Click OK to close the Add String Attribute window. 11. On the canvas, double-click the words Add String Attribute and rename the processor Add Error Status.1 Attribute With Value 'Remediated'. Add the Second Logic Check and Error Status Your second logic check will take the output from your first logic check s Fail port. In other words, it will only operate on records that did not pass the first logic check. The second logic check will determine whether you are dealing with a remediated alert that has recurred. This could happen as the result of human error for example, if the original data file was mistakenly resubmitted to the process instead of a remediated version of the file. You will be looking for errors that have a currentstate (from the last run) of Remediated, but which are also current errors. 1. In the Tool Palette, on the right-side of the screen, click to select the Audit family of processors, and then drag a Logic Check processor onto the Canvas. Page 6 of 19

7 2. Wire the Fail output of the Logic Check processor that you renamed Is this an open or reopened alert that has been remeidated? (Logic Check) to the new Logic Check processor s input port. The Logic Check window will open. 3. In the Logic Check window, select the Current Error and currentstate attributes and click to move them to the list of Selected Attributes. Page 7 of 19

8 4. Navigate to the Options tab, and configure it as displayed below: 5. Click OK to close the Logic Check window. 6. On the canvas, double-click the words Logic Check and rename the processor Is this a remediated alert that has recurred - perhaps because of human error? (Logic Page 8 of 19

9 Check). 7. In the Tool Palette, on the right-side of the screen, click to select the Transformation family of processors, and then drag an Add String Attribute processor onto the Canvas. 8. Wire the Pass output of the Logic Check processor that you renamed Is this a remediated alert that has recurred - perhaps because of human error? (Logic Check) to the Add String Attribute processor s input port. The Add String Attribute window will open. 9. In the Added Output Attributes on the right-side of the window, double-click NewString and rename the added attribute Error Status.2. Page 9 of 19

10 10. Navigate to the Options tab and enter a New Attribute Value of Recurred. 11. Click OK to close the Add String Attribute window. 12. On the canvas, double-click the words Add String Attribute and rename the processor Add Error Status.2 Attribute With Value 'Recurred'. Add the Third Logic Check Your third logic check will take the output from your second logic check s Fail port. In other words, it will only operate on records that did not pass either of the first two logic checks. The third logic check will determine whether you are dealing with a new error that has occurred for the first time (this could happen, for example, if new records are added to the data file). You will be looking for errors that have a NULL currentstate (meaning that they did not exist in the last run), but which are current errors. Page 10 of 19

11 1. In the Tool Palette, on the right-side of the screen, click to select the Audit family of processors, and then drag an Logic Check processor onto the Canvas. 2. Wire the Fail output of the Logic Check processor that you renamed Is this a remediated alert that has recurred - perhaps because of human error? (Logic Check) to the new Logic Check processor s input port. The Logic Check window will open. 3. In the Logic Check window, select the Current Error and currentstate attributes and click to move them to the list of Selected Attributes. Page 11 of 19

12 4. Navigate to the Options tab, and configure it as displayed below: 5. Click OK to close the Logic Check window. Page 12 of 19

13 6. On the canvas, double-click the words Logic Check and rename the processor Is this a completely new error? (Logic Check). Note that in this case you do not need to add an error status, since the error status is only required to inform reception rules, and reception rules are not required in order to create a new error (they are only required to change the state of existing errors). Merge the Error Status Fields, and also Merge the Records That Pass Any of the Logic Checks Back into a Single Stream Two of your three Logic Check processors are linked to Add String Attribute processors. These Add String Attribute processors each add an Error Status attribute: the attributes are called Error Status.1 and Error Status.2 respectively. (As explained above, the third Logic Check processor does not need to generate an error status.). We now want to merge these two Error Status attributes into a single attribute, which we will simply call Error Status. And whilst we are doing this, we can also join back together the Pass data streams from each of the three Logic Checks, so that we can present a single Error Message data stream for publishing to Case Management. 1. In the Tool Palette, on the right-side of the screen, click to select the Transformation family of processors, and then drag a Merge Attributes processor onto the Canvas. 2. Wire the output port of the first Add String Attribute processor, which you renamed Add Error Status.1 Attribute With Value 'Remediated' to the input port of the Merge Attributes processor. The Merge Attributes window will open. 3. Cancel out of the Merge Attributes window for now, and wire the output port of the second Add String Attribute processor, which you renamed Add Error Status.2 Attribute With Page 13 of 19

14 Value 'Recurred' to the input port of the Merge Attributes processor. The Merge Attributes window will open. 4. Again, cancel out of the Merge Attributes window for now, and wire the Pass port of the third Logic Check processor, which you renamed Is this a completely new error? (Logic Check) to the input port of the Merge Attributes processor. The Merge Attributes window will open. Do not cancel out of the Merge Attributes window this time. 5. In the Merge Attributes window, in the Available Attributes list, select Error Status.1 and Error Status.2, and click. 6. On the right-side of the window, under Merged Attributes, double click Merged, and amend the new attribute s name to Error Status. The value from either Error Status.1 or Error Status.2 will be placed in the new Error Status attribute. Note that it is logically impossible for both attributes to be populated for the same record. Note also that for new errors (those that pass the third logic check), the new Error Status attribute will be NULL. 7. Click OK to close the Merge Attributes window. 8. On the canvas, double-click the words Merge Attributes and rename the processor Create Error Status attribute (Merge Attributes). Page 14 of 19

15 Run the Process 1. In the toolbar at the top of the canvas, click to run your process. 1. Once the process has finished running, in the canvas, single-click each of the Logic Checks in turn, and, in the Results Browser, examine the passes and fails for each Logic Checks. Assuming that you have recently completed the Publishing to Case Management course, and that you have therefore already published errors from the parts.csv file, you should find that the process runs successfully, but that no records pass any of the three Logic Checks. This is entirely to be expected. All errors are existing errors, none are open, and none have been remediated. Therefore all errors fail all three checks. These errors do not need to be published to Case Management as alerts, since the alerts already created for them will persist, and do not require a change of state. Bulk Delete Your Cases and Alerts You now want to test how your process deals with new errors. To do this, you will need to bulk delete all of your existing cases and alerts, which will have the affect of emptying the cases table of its data. 1. Return to the EDQ Launchpad. Page 15 of 19

16 2. On the Launchpad, click the Case Management link to launch the user interface. Allow any Java webstart confirmation boxes that may appear so that the client software can be downloaded. If you are asked whether you want to run the application, click Run. If a dialog box warns you that the Windows Firewall has blocked some aspects of the program, click Unblock. 3. The Login to localhost dialog will open. Login with the following credentials: a. Username: dnadmin b. Password: dnadmin Page 16 of 19

17 4. The Case Management user interface opens: 5. Navigate to the Filter tab (look near the bottom-left of the screen for this). 6. In the Type box, select both Case and Alert. (To select multiple items keep your finger on the Ctrl button whilst clicking with your mouse). 7. In the Source box, select Errors. 8. Click. All of the cases and alerts for the Errors case source are displayed in a list. Page 17 of 19

18 9. Click. 10. A message will warn that the bulk operation will affect all cases that are relevant to the currently selected filter. Click OK. 11. A message will be displayed warning that the process may take some time (it won t as we only have a small number of cases and alerts). Click OK to dismiss the message. 12. Near the top-left of the screen, click. As you have deleted all of the cases and alerts, the list should now appear empty. Purge Your Project In order to properly test how your process deals with new errors, you will also need to purge your project. This will delete the project s staged data and its results. 1. Return to the Director user interface. 2. In the Director UI s Project Browser right-click your Case Management Training project, and select Purge Project. Page 18 of 19

19 3. A dialog will ask you if you are sure that you want to purge all of the data from the project. Click OK. 4. If prompted, Save any changes. Run the Snapshot and the Process 1. In the Director UI s Project Browser expand the Staged Data node within your Case Management Training project. 2. Right-click the Case Management Tables.cases snapshot, and select Run. 3. Right-click the PARTS Table snapshot, and select Run. 4. In the Director UI s Project Browser expand the Processes node within your Case Management Training project. 5. Right-click the 1.Audit Data Records process, and select Run. 6. Once the 1.Audit Data Records process has finished running, double-click the 2.Publish Alerts to Case Management process to open it on the canvas. 7. At the top of the canvas, click to run the 2.Publish Alerts to Case Management process. 8. Once the 2.Publish Alerts to Case Management process has finished running, in the canvas, single-click each of the Logic Checks in turn, and, in the Results Browser, examine the passes and fails for each Logic Checks. On this run, you should find that all of the records fail the first two Logic Checks, but that all of the records pass the third and final Logic Check. This is because, since we have bulk deleted the cases and alerts from Case management, and purged all of the staged data from our project, all errors are treated as new errors. We are not yet in a position to test whether all three of our Logic Checks work as we would expect, but we will do this in a later lab. Page 19 of 19