Underlying Inbound Interface
Overview
Underlying can be loadedÂ
with a dedicated interface Reference Underlying SMF via eagle_ml-2-0_default_in_xml_reference stream (objectType = UnderlyingSMF)
with SMF via eagle_ml-2-0_default_in_xml_smf_generic stream (objectType = GenericSMF with UnderlyingModel)
Related rules
Default rule for Underlying processing is xml-smf_underling.xml
If the Batch Key is set, the data is routed to xml-smf_underling_batch.xml
Related Stored Procedures
PACE_MASTERDBO.ESTAR_SEC.INSERT_UPDATE_UNDERLYING_INFO - Insert and Update
PACE_MASTERDBO.ESTAR_SEC.DELETE_UNDERLYING - Delete
Related Panels
eagle/star/reference/pan-addunderlying-security.htm
eagle/star/reference/pan-chgunderlying-security.htm
eagle/star/reference/pan-delunderlying-security.htm
On this page
- 1 Overview
- 1.1 Single Row Mode
- 1.1.1 Delete Process
- 1.1.2 Processing Options and Config Parameters
- 1.1.2.1 Underlying Delete Reinsert Switch
- 1.1.2.2 Underlying Retain Begin Date Switch
- 1.1.2.3 Unique Record Switch
- 1.2 Batch Mode
- 1.1 Single Row Mode
Single Row Mode
Delete Process
To delete Underlying records, add the following header with DELETE action set in every referenceTransaction and send file to the eagle_ml-2-0_default_in_xml_reference stream.
<header>
<objectType>UnderlyingSMF</objectType>
<action>DELETE</action>
</header>
Record will be deleted by key- securityAlias + underlyingSecurityAlias + beginDate
Only record with null END_DATE in Data Base can be deleted using this method. For other delete methods please check Underlying Delete Reinsert Switch and Underlying Batch Reinsert Mode.
Processing Options and Config Parameters
Underlying Delete Reinsert Switch
Global parameter - W_UNDERLYINGSMF_DELETE_REINSERT_SWITCH
Local parameter -Â underlyingDeleteReinsertSwitch
Setting to Y allows to delete the underlying record by SecurityAlias + UnderlyingSecurityAlias key and reinsert a new incoming one.
Underlying Retain Begin Date Switch
Global parameter -Â W_UNDERLYINGSMF_RETAIN_BEGIN_DATE_SWITCH
Local parameter -Â underlyingRetainBeginDateSwitch
Setting to Y allows to control the logic for the begin date and end date for underlying security relationships.
The new setting enables the following logic:
Maintains a single underlying record per relationship with a null end date, where the record key = Security alias + Underlying type.
To avoid such behavior the beginDate with 'currentdate' valuse can be used. It will allow to keep multiple Security alias + Underlying type records with null end date and different Underlying Security Aliases.Â
Example of usage:<underlyingSMF> <underlyingRetainBeginDateSwitch>Y</underlyingRetainBeginDateSwitch> [...] <beginDate>currentdate</beginDate> </underlyingSMF>
Updates the existing DB record in case the record key = Security alias + Underlying type + Underlying security alias, but does not update the existing begin date in DB
Retains all the default rules for underlying SMF records
Unique Record Switch
Global parameter - W_UNDERLYINGSMF_UNIQUE_RECORD_PER_TYPE_SWITCH
Processing Option - UNIQUE_RECORD_PER_UNDERLYING_TYPE
There will be only one record, meaning that only one underlying SMF will be open for a combination of Main Security Alias + Underlying Type.
If there is an open record for the same combination of Main Security Alias and Underlying Type as that of the incoming record, the open record will now be closed with the end date = incoming begin date - 1.
This option may be turned on via the global flag W_UNDERLYINGSMF_UNIQUE_RECORD_PER_TYPE_SWITCH set to Y or within the incoming file.
Example of usage:
<header>
<objectType>UnderlyingSMF</objectType>
<processingOptions>UNIQUE_RECORD_PER_UNDERLYING_TYPE</processingOptions>
</header>
This new option may be used independently or in combination with the W_UNDERLYINGSMF_DELETE_REINSERT_SWITCH.
If both the W_UNDERLYINGSMF_DELETE_REINSERT_SWITCH and W_UNDERLYINGSMF_UNIQUE_RECORD_PER_TYPE_SWITCH are set to Y, the expected behavior is as follows:
The existing records with the same security alias (main security) + underlying alias (underlying security) as that of the incoming record are deleted before load.
All open records with the same Main security and Underlying Type will be closed with the end date = incoming begin date -1.
An error is thrown when the incoming begin date is less than the existing begin date in the database.
A new record is stored in the database.