Customization DMBS

11/17/2019 Customizations
By clicking here, you understand that we use cookies to improve your experience on our website. For more details, please see our Cookie Policy. ×
 TechDocs
CA DATA PROTECTION 15.0
Version 15.0  English
Product Menu 
Customizations
Last Updated September 6, 2019
To configure the Review Queue for specific customer configurations there are various elements that can be customized. This section
covers the customization points are, its purpose, and the default values.
Customizable Views
Customizable Stored Procedures and Functions
Customizable Views
General
To customize a view, a new view must be created with the same interface as the distributed view but with a name that has an extra
suffix of CUST.
For example, to customize this view:
WGN_V_RQ_CRITERIA_CLOSED_1,
Create the following new view:
WGN_V_RQ_CRITERIA_CLOSED_1_CUST
This new view has the same columns that are defined as the original view:
WGN_V_RQ_CRITERIA_CLOSED_1.
WGN_V_RQ_CRITERIA_CL_1 View
Purpose
A view that returns event participant references for all participants that meet the criteria for removal from the Review Queue. This
view is used to determine the queue entries to be purged, which are no longer presented for review.
Default
Returns participant references for all events that have an audit issue with current audit entry with audit type of 1 and a value of '1'.
This configuration is the default configuration that defines an 'Approved' audit issue.
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/it-operations-management/ca-data-protection/15-0/implementing/iconsole-review-queue-conﬁguration/customizations.html 1/13
Note
In the case of this view WGN_V_RQ_CRITIERIA_CL_1, it is necessary to update this view manually to select from the
customized version WGN_V_RQ_CRITERIA_CL_1_CUST by simply replacing the reference to
WGN_V_RQ_CRITERIA_CL_1_DEF with WGN_V_RQ_CRITERIA_CL_1_CUST.
WGN_V_RQ_EVENT_SLICE_1 View
Purpose
A view that returns a portion of the total events that are considered as candidates for the Review Queue as part of the current run.
Default
Returns ALL events from the Wgn3RTEventSlice table.
Note
In the case of this view WGN_V_RQ_EVENT_SLICE_1, it is necessary to update this view manually to select from the
customized version WGN_V_RQ_EVENT_SLICE_1_CUST by simply replacing the reference to
WGN_V_RQ_EVENT_SLICE_1_DEF with WGN_V_RQ_EVENT_SLICE_1_CUST.
Customizable Stored Procedures and Functions

This section refers to the logical names of customizable routines. However, the actual naming of procedures or functions in SQL Server
and Oracle differ and has the logical names prefixed with 'WGN_RQ_' and 'WGN_RQ.' respectively.
General
To customize a stored procedure, a new stored procedure must be created, that has the same interface as the distributed stored
procedure, but with a name that replaces the characters STUB_x. For:
SQL Server
The suffix STUB_x must be replaced with CUSTOM_x, where 'x' is the version number.
Oracle
The STUB_x suffix must be removed.
For example, in SQL Server, to customize the stored procedure WGN_RQ_SET_METRICS_STUB_1, a new stored procedure named
WGN_RQ_SET_METRICS_CUSTOM_1 must be created. This stored procedure has the same interface defined as
WGN_RQ_SET_METRICS_STUB_1.
The above applies to functions as well as to stored procedures.
SET_METRICS_STUB_1
Purpose
Allows the metrics that defined on a per group basis how the queues are to be built. These metric are stored in a database table that
is called WGN3REVIEWMETRICS. For example, if there is a group that has a unique identifier of groupidm=1 and groupid=104, and
the metrics required for this group are:
Retrieve 5 percent of triggered events with a minimum of 10 events and a maximum 50 events then the implementation of these
metrics would be as follows.

Default
Defines a single metric for all groups to retrieve all triggered events.
SQL Server
EXEC WGN_RQ_METRIC_INSERT_1 1,104,0,5,0,'P','P'
EXEC WGN_RQ_METRIC_INSERT_1 1,104,1,10,1,null,'A'
EXEC WGN_RQ_METRIC_INSERT_1 1,104,2,50,1,null,null
Oracle
EXEC WGN_RQ.METRIC_INSERT_1(1,104,0,5,0,'P','P');
EXEC WGN_RQ.METRIC_INSERT_1(1,104,1,10,1,null,'A');
EXEC WGN_RQ.METRIC_INSERT_1(1,104,2,50,1,null,null);
The parameters to METRIC_INSERT_1() correspond to the metric attributes of the same name, including two final optional
parameters, DGrouping and Process.
The DGrouping parameter defaults to 'null' which is interpreted as 'no data grouping' applied' setting to a value of '1' means that
'data groupng is applied' if applicable.

The final parameter to METRIC_INSERT_1() which defaults to a value of 1 and corresponds to the process metric attribute.
Non default values, define discrete sets of review metrics identified by that number, for example a weekly versus monthly set. To
invoke with a non default (1) set of metrics is done by specifying as the process argument to POPULATE_QUEUE().
Note
For SQL Server,the process id is also used in determining the names of the following customizations, where the value of
<n> is mapped to the process argument supplied to POPULATE_QUEUE:
GET_TYPE_A_PRED_CUSTOM_n_1
GET_TYPE_P_PRED_CUSTOM_n_1
GROUPING_MAIN_CUSTOM_n_1
GROUPING_MAND_CUSTOM_n_1
For Oracle, these per process customizations are done by passing the Process Id to the routines.
DERIVE_UPPER_BOUND_STUB_1
Purpose
When the Review Queues are populated a range of Events between a lower and upper bound is considered as candidates for the
Review Queue. The lower bound is always defined as the upper bound from the previous run (except on the first run or if specific
bounds are specified). This procedure allows the derivation of the upper bound to be customized.
Default
Derives the upper bound as being one day's worth of events since the previous run, so the default assumes that the process runs
once per day.
GET_SAMPLE_SIZE_STUB_1
Purpose
This function returns the number of DAYS that is used to determine the upper bound of events. It is important to note that this
sample offset is based on UpdateTimeStamp, which is the creation date of the event record in the database. An example of a
customization may be a requirement to use a sample size of one hour's worth of events. In this case, the custom function would
merely specify 'RETURN (1/24)'.
Default
1 (DAY)
DAY_ALIGN_STUB
Function Name
The name of this function varies by DBMS.
On Oracle CMSs, the function is:
GET_DAY_ALIGN_STUB
On SQL Server CMSs, the function is:
DAY_ALIGN_STUB
Purpose
This function acts as a switch, and can be customized to return either true or false. The default to retain compatibility with older
versions is to return false. So by default, Review Queue does not operate in 'day align mode'. The sections below illustrates the
behavioral difference between Review Queue operating in 'day align mode' and 'non day align mode'.
Default
false/0
On Oracle, this function returns a Boolean value of true or false, so it needs to return true to switch to 'day align mode'.
However, on SQL Server there is no support for Boolean datatypes, so it needs to return a non zero (1 by convention) to switch to
'day align mode'.
Day Align Mode
1. When the Review Queue selects the events that are candidates to be placed onto the queue, it attempts to select every event
from the calendar day on which the upper bound of the next run would occur. This means that, by default, if the sample size is
set to 1 day then each run of Review Queue will select all the events from the next calendar day as candidates, and not just
those that are within the 24 hour window that follows chronologically from the highest event of the previous run. This means that
the event window is used to select events from the Review Queue will not 'slip' over time.
2. When there are insufficient events to satisfy the sample size (default 1 day), the Review Queue will simply process those events
that are available. It will not abandon without processing.

Non Day Align Mode
1. When the Review Queue selects the events that are candidates to be placed onto the Review Queue, it attempts to select every
event that lies within the window defined by the last event processed by the previous run plus the sample size. It makes no
attempt to align this window on any boundary, and simply selects the sample size as defined by GET_SAMPLE_SIZE_STUB.
2. When there are insufficient events to satisfy the sample size (default 1 day), the Review Queue will ABANDON, and not process
any events until there is are sufficient events available to satisfy the sample size. Note that from release 12.0, when this occurs
an entry gets written to WGN3QUEUESTATE to indicate that the Review Queue was abandoned due to insufficient events being
available to process.
Examples
Using the default sample size of 1 day, consider that on Dayx the Review Queue ran and processed events up to and including
an event that occurred at 23:45:20pm. When the Review Queue runs on Dayx+1, the highest event that occurred on that day
occurred is at 23:58:00pm (slightly more than 24 hrs ahead of the highest from Dayx), and on Dayx+1 there also exists an event
that occurred at 23:45:20pm (exactly 24 hrs of the highest from Dayx). If the Review Queue is operating in 'day align mode' then
it will process events on Dayx+1 up to and including the one that occurred at 23:58:00pm. Conversely, in 'non align mode' it
will process events on Dayx+1 only up to and including the one that occurred at 23:45:20pm, but those that occurred between
23:45:20pm and 23:58:00pm will not be processed until the Review Queue runs on Dayx+2.
Using the default sample size of 1 day, consider that on Dayx the Review Queue ran and processed events up to and including
an event that occurred at 23:45:20pm. When the Review Queue runs on Dayx+1, the highest event that occurred in the system
occurred at 09:00:00am on Dayx+1 (so there is only around 9:15 hrs worth of candidate events, which is less than the 1 day as
required by the sample size). If the Review Queue is operating in 'day align mode' then it will successfully process events on
Dayx+1 up to and including the one that occurred at 09:00:00am. Conversely, in 'non align mode' it will abandon and process no
events because it insists on processing a full sample of events.
GET_CTAS_LIMIT_STUB_1
Purpose
Part of the queue management process requires that entries be physically removed (purged) from the queue once they meet the
criteria that defines they are closed. When purging the queue, it can be more efficient to create a new queue that just contains the
'Open' entries rather than deleting every entry that is 'Closed', if the number of entries to delete is a high percentage of the total. This
method allows that that threshold to be customized.
Default
80%
GET_SORT_PRECEDENCE_STUB_1
Purpose
Allows optimization if the order in which the results are to be displayed in the search is more than simple FIFO or LIFO (such as
when the triggered events must be displayed before non-triggered events).
Note
This function is not relevant in Oracle.
Default
Triggered event are given higher precedence than non-triggered.
GET_TS_LOWER_BOUND_STUB_1
Purpose
Allows an additional restriction to be applied when choosing events as candidates for Review Queue by specifying an additional
lower bound on EventTimeStamp. This will help performance on partitioned systems.
SQL Server default
None. No additional filter on EventTimeStamp is added.

Oracle default
In Oracle the EventTimeStamp predicate has already been considered by default to help query performance, particularly where
partitioning is present, which should normally be the case. If there are no bounds input to the process or bounds are not available
from any previous runs, then the minimum EventTimeStamp value is used as a lower bound.
GET_TYPE_A_PRED_STUB_1
Purpose
The Review Queue is built from events between an upper and lower bound (see DERIVE_UPPER_BOUND_STUB_1) within these
bounds there are conceptually two distinct sets of data. These are:
Type A
All data. This is the full set of events within the upper and lower bound that are to be considered when building the Review
Queue. An example of Type A predicate would be to only include e-mail and IM events but exclude Web events.
Type P
Prime data. This is the prime target for the main selection that drives the queue building.
If this procedure is customized, it must return an SQL subquery that projects the eventuid and EventTimeStamp pairs of events
that are considered Type A.
Default
Null. All events within the lower and upper bounds are candidates for review.
SQL Server custom implementation
In SQL Server, the custom function must always be named WGN_RQ_GET_TYPE_A_PRED_CUSTOM_n_1 where 'n' is the RQ
Process number for which this function applies.
If the name of the custom function(s) deviates from that stipulated above then the RQ process to populate the Review Queue will me
rely ignore it and subsequently it will fail to implement the intended custom behavior.
Oracle custom implementation
In Oracle, the custom function is contained within the stored package WGN_RQ_CUST and must always be named
WGN_RQ_CUST.GET_TYPE_A_PRED. Additionally, the process number is passed to this function such that multiple
implementations can be coded on a per process basis by using a PL/SQL CASE construct. The custom package body is contained
within the supplied file WGN_RQ_BODY.sql and can be modified accordingly.
GET_TYPE_P_PRED_STUB_1
Purpose
See the previous description.
Type P data is the prime target for the main selection that drives the building of the queue. An example of Type P predicate could be
to define that the prime target for selection is events that have triggered policy.
If this procedure is customized, then it has to return an SQL sub query, that projects the eventuid and eventtimestamp pairs of
events that are to be considered Type P data.

Default implementation
Select only those events that have triggered policy.

In SQL Server, the custom function must always be named WGN_RQ_GET_TYPE_P_PRED_CUSTOM_n_1 where 'n' is the RQ
Process number for which this function applies. If the name of the custom function(s) deviates from that stipulated above, the RQ
process to populate the Review Queue merely ignores it and it fails to implement the intended custom behavior.
WGN_RQ_CUST.GET_TYPE_P_PRED. Also, the process number is passed to this function such that multiple implementations can
be coded on a per process basis by using a PL/SQL CASE construct. The custom package body is contained within the supplied file
WGN_RQ_BODY.sql and can be modified accordingly.
VALIDATE_BOUNDS_STUB_1
Purpose
As described earlier, the events that are considered candidates for placing on Review Queue are between a lower and upper bound
(see DERIVE_UPPER_BOUND_STUB_1). Due to operational procedure, it may be necessary to determine whether the bounds are
valid.
For example there may be an operational constraint that dictates that a minimum of 1000 events must be eligible for selection before
the process can run.
Customizing this allows those operational constraints to be enforced.
If the result of this validation proves false, then the Review Queue population is abandoned, and can be viewed as such.
Default
Returns false if the upper bound is greater than the highest event in the system.
MAIN_GROUPING_STUB_1
Note
In SQL Server this function is standalone and named differently as described further down. There is no Stub version.
Purpose
Function that returns the user-defined grouping to be defined for metric categories 0,1 and 2. Note as the actual type of the grouping
is unknown it must be returned as a character string. Only groups that have the appropriate DGrouping setting of 1 are subject to
this level of grouping. This function is called to attach a user-defined value to each event that allows totals to be computed grouped
by that value. Examples are 'user' 'direction' 'hour'.
The function takes the following arguments that are listed. These are the respective attributes from the event to which the user-
defined value is to be attached.
eventuid
eventtimestamp
ParticipantIndex
groupidm
groupid
useridm
userid
AddressUID1
AddressUID2
ParticipantNodeUID
InterventionNodeUID
eventmajortype
Default Implementation
Returns NULL.
In SQL Server, the custom function must always be named WGN_RQ_GROUPING_MAIN_CUSTOM_n_1 where 'n' is the RQ
Process number for which this function applies. If the name of the custom function(s) deviates from that stipulated earlier, the RQ
process to populate the Review Queue merely ignores it and subsequently, it fails to implement the intended custom grouping
behavior.
WGN_RQ_CUST.GROUPING_MAIN. Also, the process number is passed to this function such that multiple implementations can be
coded on a per process basis by using a PL/SQL CASE construct. The custom package body is contained within the supplied file
WGN_RQ_BODY.sql and can be modified accordingly.
MAND_GROUPING_STUB_1
Note
In SQL Server this function is standalone and named differently as described further down. There is no Stub version.
Purpose
Same purpose as for section MAIN_GROUPING_STUB_1function described previously, but used to derive user-defined data
grouping for the category 3 metric -- Mandatory Selection.
Default implementation
Returns NULL.

In SQL Server, the database stored function must always be named WGN_RQ_GROUPING_MAND_CUSTOM_n_1 where 'n' is the
RQ Process number for which this function applies. If the name of the custom functions deviates from that stipulated earlier,then the
RQ process to populate the Review Queue merely ignores them and it later fails to implement the intended custom grouping
behavior.
The following code is an example of how to implement such a function for a mandatory selection of 'at least 1 event per user'. It
assumes that it applies for the default RQ process "1". It makes the assumption that the input parameter @userid can be
guaranteed to identify a CA Data Protection user. This is an assumption that may or may not be valid depending on how CA Data
Protection is deployed. If this is not true, then a combination of @useridm and @userid must be used (as they comprise the formal
unique identifier of a CA Data Protection user in the database)> But to retain the simplicity of the example, that assumption is made
here.
This function is invoked for each event participant who is a potential candidate for Review Queue. The parameters that are passed
are the respective values for each event participant. Because it is generic in nature, it must return a value of type nvarchar. This is
why the @userid must be cast.
SQL Server
CREATE FUNCTION WGN_RQ_GROUPING_MAND_CUSTOM_1_1 (
@eventuid bigint ,
@eventtimestamp datetime ,
@ParticipantIndex int ,
@groupidm int ,
@groupid int ,
@useridm int ,
@userid int ,
@AddressUID1 bigint ,
@AddressUID2 bigint ,
@ParticipantNodeUID int ,
@InterventionNodeUID int ,
@eventmajortype int
)
RETURNS nVarchar(512)
AS
BEGIN
return cast(@userid as nvarchar(512))
END
To implement 'at least 1 event per user', this requires a metric of category '3' which is the Mandatory selection metric. The
interpretation of the metric attributes is identical to the other metric categories, so the example below is interpreted as 'Include a
minimum of 1 event per data grouping from type A data'. However, the metric does not define how the data group is implemented (in
this instance it is per user), that is done by the function above. Setting the value of Data Grouping to '1' is merely stating that the
metric is to be applied using the defined data grouping, but not how that grouping is implemented.
Metric Category: 3
Metric Value:1
Metric Type: 1
Metric Target: -
Data Target: A
Data Group: 1
Assuming that for the Group (1,105) we wish to apply the above metric then the implementation of that additional metric is shown
below:
SQL Server
CREATE PROC WGN_RQ_SET_METRICS_CUSTOM_1
AS
BEGIN
truncate table wgn3reviewmetrics

/*
Other metrics from previous example omitted
*/

-- The metric below defines 1 per user for group 1,105
EXEC WGN_RQ_METRIC_INSERT_1 1,105,3,1,1,null,'A',1,1

END

WGN_RQ_CUST.GROUPING_MAND. Additionally, the process number is passed to this function such that multiple
implementations can be coded on a per process basis by using a PL/SQL CASE construct. The custom package body is contained
within the supplied file WGN_RQ_BODY.sql and can be modified accordingly.
The following code is an example of how to implement such a function for a mandatory selection of 'at least 1 event per user' and it
assumes it applies for the default RQ process '1'. It makes the assumption that the input parameter p_UserID can be guaranteed to
uniquely identify a CA Data Protection user. This is an assumption that may or may not be valid, depending on how CA Data
Protection is deployed. (If this were not true then a combination of p_UserIDM and p_UserID would need to be used because they
comprise the formal unique identifier of a CA Data Protection user in the database, but to retain the simplicity of the example that
assumption is made here.)
This function is invoked for each event participant who is a potential candidate for the Review Queue, and the parameters that are
passed are the respective values for each event participant. Because it is generic, it has to return a value of type VARCHAR2,
hence the reason why the p_UserID has to be cast.
Oracle
FUNCTION Grouping_Mand ( p_EventUID IN NUMBER,
p_EventTimeStamp IN DATE,
p_ParticipantIndex IN NUMBER,
p_GroupIDM IN NUMBER,
p_GroupID IN NUMBER,
p_UserIDM IN NUMBER,
p_UserID IN NUMBER,
p_AddressUID1 IN NUMBER,
p_AddressUID2 IN NUMBER,
p_ParticipantNodeUID IN NUMBER,
p_InterventionNodeUID IN NUMBER,
p_EventMajorType IN NUMBER,
p_Process IN NUMBER DEFAULT 1 )
RETURN VARCHAR2
IS
BEGIN

-- This procedure is customizable per process and therefore the following
-- constructs must be strictly adhered to.

CASE p_Process

WHEN 1 THEN

RETURN TO_CHAR(p_UserID);

WHEN 2 THEN

-- To use custom code the default call below must be commented out
-- and additional custom code provided in it's place.

-- invoke default routine
RETURN WGN_RQ.Grouping_Mand_Def_1(p_EventUID,p_EventTimeStamp,p_ParticipantIndex,
p_GroupIDM,p_GroupID,p_UserIDM,p_UserID,
p_AddressUID1,p_AddressUID2,
p_ParticipantNodeUID,p_InterventionNodeUID,p_EventMajorType);

ELSE

-- DO NOT CUSTOMIZE

-- invoke default routine
RETURN WGN_RQ.Grouping_Mand_Def_1(p_EventUID,p_EventTimeStamp,p_ParticipantIndex,
p_GroupIDM,p_GroupID,p_UserIDM,p_UserID,
p_AddressUID1,p_AddressUID2, p_Participan
tNodeUID,p_InterventionNodeUID,p_EventMajorType);

END CASE;

END Grouping_Mand;
To implement 'at least 1 event per user' requires a metric of category '3' which is the Mandatory selection metric. The interpretation
of the metric attributes is identical to the other metric categories, so the example below is interpreted as 'Include a minimum of 1
event per data grouping from type A data'. However the metric does not define how the data group is implemented (in this instance it
is per user), that is done by the function above. Setting the value of Data Grouping to '1' is merely stating that the metric is to be
applied using the defined data grouping, but not how that grouping is implemented.
Metric Category: 3
Metric Value: 1
Metric Type: 1
Metric Target: -
Data Target: A
Data Group: 1
Assuming that for the Group (1,105) we wish to apply the above metric then the implementation of that additional metric is shown
below:
Oracle
PROCEDURE Set_Metrics
IS
BEGIN

-- Default is to insert metric parameters for top-level group only.
-- All other sub-groups inherit this.

-- Wgn_RQ.Set_Metrics_Def_1;

-- To use custom code the default call above must be commented out.
-- Provide custom code as follows by always using the specific
-- procedure/function calls where stated:

-- purge existing metrics
-- <<MANDATORY>>
WGN_RQ_EXEC_DDL.Truncate_Table('Wgn3ReviewMetrics');

-- insert new metrics
-- <<OPTIONAL>>

-- Other metrics from previous example omitted

-- The metric below defines 1 per user for group 1,105
WGN_RQ.METRIC_INSERT_1(1,105,3,1,1,null,'A',1,1);

END Set_Metrics;
Products
Applications
Support
Company
How to Buy
Copyright © 2005-2019 Broadcom. All Rights Reserved. The term 'Broadcom' refers to Broadcom Inc. and/or its subsidiaries.
Privacy Policy Cookie Policy Terms of Use Sitemap
    

Customization DMBS

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Customization DMBS

Hochgeladen von

Copyright:

Verfügbare Formate

11/17/2019 Customizations

CA DATA PROTECTION 15.0

Version 15.0  English

Create the following new view:

Returns ALL events from the Wgn3RTEventSlice table.

Customizable Stored Procedures and Functions

metrics would be as follows.

parameters, DGrouping and Process.

'data groupng is applied' if applicable.

<n> is mapped to the process argument supplied to POPULATE_QUEUE:

once per day.

merely specify 'RETURN (1/24)'.

The name of this function varies by DBMS.

On Oracle CMSs, the function is:

On SQL Server CMSs, the function is:

Day Align Mode

that are available. It will not abandon without processing.

This function is not relevant in Oracle.

None. No additional filter on EventTimeStamp is added.

events that are to be considered Type P data.

Select only those events that have triggered policy.

SQL Server custom implementation

Oracle custom implementation

Privacy Policy Cookie Policy Terms of Use Sitemap

Das könnte Ihnen auch gefallen