Sub-request parameters
Configuring Sub-Request Ownership
By default, when the status of a change request changes, the owner of the parent request is not automatically assigned to the sub-requests. Configure this behavior as needed, for all or specific status changes.
Tip: This parameter is particularly relevant when using the GetRealGroupName hook. For details, see GetRealGroupName .
| Configuration Parameter Name | Value |
|---|---|
| DoNotCopyOwnerToSubTicketsStatuses |
{"All":1}. (Default) Determines that sub-requests never inherit the owner value from their parent request. {"None":1}. Determines that sub-requests always inherit the owner value from their parent request. |
Configuring Sub-requests to Include Traffic for the Whole Change Request
Note: If the network map is inaccurate (paths are missing in), it is advised to disable the FIP algorithm in AFA. In this case, this feature will automatically be disabled and sub-requests will consequently include all traffic.
| Configuration Parameter Name | Value |
|---|---|
| PerSubRequestTrafficDifferentiation |
0. To configure sub-requests to include all traffic lines as is. 1. To configure sub-requests to include only traffic lines in path and to modify their values according to NAT taking place in devices in the path. (Default) |
Enabling/Disabling Sub-Request Traffic Modification
By default, FireFlow does not allow users to modify traffic specified in sub-requests. If desired, you can enable sub-request traffic modification.
Note: When traffic modification in sub-requests is enabled you may edit existing traffic lines in sub-requests. Addition and removal of traffic lines is never allowed.
| Configuration Parameter Name | Value |
|---|---|
| ModifySubTicketChangeTraffic |
0. To disable sub-request traffic modification. (Default) 1. To enable sub-request traffic modification. |
Configuring the Risk Check Method for Change Requests with Multiple Devices
In the Approve stage of a traffic change request's lifecycle, FireFlow performs a risk check, to determine whether implementing the change specified in the change request will introduce risks. The risk check is run on the device(s) specified in the change request, using the Risk Profile that the device was assigned when generating the last successful report in AFA.
When performing a risk check for a parent request with sub-requests, there are multiple devices and potentially multiple Risk Profiles involved. You can configure FireFlow to use any of the following risk check methods:
FireFlow runs the risk check on one random device out of all the sub-request devices.
For example, let us assume that there are three sub-requests, as follows:
|
Sub-request |
Device |
Risk Profile |
|---|---|---|
|
500 |
Check Point A |
r1 |
|
501 |
Check Point B |
r2 |
|
502 |
Cisco C |
r1 |
FireFlow will select a device at random (such as Cisco C) and run the risk check on it (using Risk Profile r1).
Only risk check results for the selected device will be displayed.
FireFlow runs the risk check on one random device per Risk Profile used by the sub-request devices.
In our example, there are two Risk Profiles, r1 and r2. FireFlow will select a device at random (either Check Point A or Cisco C) to run the risk check on using Risk Profile r1, and it will also run a risk check on Check Point B using Risk Profile r2.
Risk check results will be displayed per risk profile.
FireFlow runs the risk check on each of the sub-request devices.
In our example, FireFlow will run a risk check on Check Point A, Check Point B, and Check Point C, using their respective Risk Profiles.
Note that the risk check may take a while, and the results for each device may be similar.
Risk check results will be displayed for each device.
| Configuration Parameter Name | Value |
|---|---|
| RiskCheckOnParentTicket |
one. To use the One method. profile. To use the Profile method. (Default) all. To use the All method. |
Yes 
No 
