Visible Publisher Identifier
Identifying the Author of a Price
In an organisation the Market Data System that provides services to discover and publish pricing information, entitlement controls that ensure that only authorized users can contribute that pricing is an important element in maintaining the integrity of the information and the Refinitiv Enterprise Platform (TREP) provides the entitlement controls to enable this; But the next step is to establish accountability for the information published, whether this is a publisher internal to the organisation or sent on to an external Vendor, such as Refinitiv. Accountability requires audit logging that can identify the price, the time it was sent and crucially who sent it and from where.
Logging the price data and time sent has always been technically possible for contribution servers operating on Enterprise Platform but how do we find out who sent it and from where?
Answer: Visible Publisher Identifier (VPI).
Visible Publisher Identifier
The VPI is a licensable feature that provides a means to identify the originator of a post, insert or publish message made to an interactive provider or to a non-interactive service cache on the platform.
The VPI consist of a unique user identifier and an IP-Address.
The User Unique Identifier
The user unique identifier is contained in an unsigned 32 bit integer (UInt32) value consisting of the DACS Station Identifier and the DACS User Identifier in the following format:
<DACS Station Id><DACS User Identifier>
e.g. 7f000013
Where :
DACS Station Id = 7f
DACS User Identifier = 000013
See also DACS Reference Manual "Unique User ID Lookup".
When a user login is requested the ADS extracts the unique user identifier from the users DACS profile in order to construct the VPI when a post or insert message is received.
The Originator Address
The address component of the VPI information is the IP Address of the originator encoded in an unsigned 32 bit integer.
e.g.
IP Address = 10.14.132.159
Converting each octet into its hexadecimal value: 10 = 0A, 14 = 0E, 132 = E8, 159 = 9F
Will results in a UInt32 value = 0A0E849F
Using the VPI information
A consumer application will login to an ADS and for a successful login the user permission profile will be held in the ADS memory. The entitlement profile contains the unique user identifier which is accessed by the ADS along with the position supplied during login to populate the VPI information when the consumer application posts data to a service.
No VPI information is required from the consumer application with this arrangement and the Provider application will receive the VPI information as supplied by the ADS.
Specifying the VPI information
OMM Provider applications may optionally specify the VPI information in Refresh and Update response messages so that this information is available to downstream consumers.
As a consumer application the EMA, ETA and current versions of RFA offer a means to specify the VPI information. This supports use cases in which the consumer application is a server, providing its clients with a means to post data onto a TREP service. Being able to specify the VPI information at the API means that the application can still provide the necessary information about the originator.
This is a specific use-case which requires the use of a permission variable in order to instruct the ADS to preserve the VPI information in the PostMsg when it sends the message to the service, otherwise the ADS would populate the message using the VPI information of the directly connected user, in this case the server application. See the DACS Reference Manual “DONOTOVERRIDE” under “Optional User Variables”.
Accessing the Unique User Identifier
In order to specify the VPI information an application must have a means to access the unique user identifier and this can be extracted from the DACS User permission variable "U.UNIQUEID" using the OpenDACS AuthorizationAgent method : getPermissionVariable(); as shown in the Java code extract below:
AuthorizationCheckResult result = null;
AuthorizationCheckStatus authCheckStatus = new AuthorizationCheckStatus();
String[] vdata = new String[1];
try {
result = authAgent.getPermissionVariable(loginHandle, authCheckStatus, "U.UNIQUEID", vdata);
if( result == AuthorizationCheckResult.ACCESS_ALLOWED )
{
System.out.println("AuthorizationCheckResult.ACCESS_ALLOWED\n");
if( vdata[0] == null )
System.out.println("Variable "+var+" empty");
else
System.out.println("Variable "+var+"="+vdata[0]);
}
else
System.err.println("getPermissionVariable("+var+") failed. "+authCheckStatus.getStatusText());
}
catch(AuthorizationException authEx )
{
System.err.println(authEx.getClass().getName()+" "+authEx.getMessage());
}
This information can also be extracted from the DACS Station. The example extract below uses the DacsWSClient utility program supplied with the DACS release and described in the DACS Web Services Programmer's Guide (See Appendix "DacsWSClient.jar Utility").
radmin@cs7devi# java -jar DacsWSClient.jar
>sm http://cs7dev:8080
>sup <admin user> <admin password>
>gul 5CS *
List of DACS users passing filter:
60_MCA_IDN
67_ITEM_REQUIREMENT
A.Smith
A.Wang
app1
nakamoto
odps
radmin
>gud 5CS A.Smith
DACS users definition:
Login - A.Smith
Name - Agent Smith
Admin group - user_group
Department - Training
Cost Center -
Location - London
Description -
Email -
Unique ID - 11
Allowed Simultaneous Login - 1
Allow Authorization Migration - false
Require Authorization - false
The Unique ID can be seen above presented as a decimal number 11, without the DACS Station Identifier. With a DACS Station Id of 7f ,this Unique ID presented at the API will be 7f00000B.
Accessing the VPI information on the Provider Application
The Elektron SDK and the RFA SDK both have Provider examples that demonstrate how an application can access VPI information in a Post message;
ETA Provider
The Elektron SDK 1.2.2 Java release contains an ETA provider example located in [Eta\Applications\Examples\src\main\java\com\thomsonreuters\upa\valueadd\examples\provider]
Within the method ItemHandler.processPost() shown below, which as the name suggests, handles Post messages the following code extract demonstrates how the VPI information in the PostMsg is accessed using the API PostMsg.postUserInfo() method in order to populate the VPI information in the resulting RefreshMsg response.
RFA Posting Provider
The RFA Java SDK 8.1.0.L1 Posting Provider example is located in [Examples\com\reuters\rfa\example\omm\postingProvider] and shows how the VPI information is accessed in PostProviderClientSession.java using the OMMMsg.getPrincipalIdentity() method.
Accessing VPI information in a Consumer Application
An OMM Consumer application can access the VPI information in response messages where this is populated by the provider application.
EMA Consumer
The OmmConsumerClient methods defined within an EMA Consumer application which handle response messages, such as onRefreshMsg() can add a check for the presence of a publisherId using the RefreshMsg.hasPublisherId() method, there are also corresponding methods for UpdateMsg and StatusMsg. Where the publisherId is present, the VPI information can be accessed using methods publisherIdUserId() and publisherIdUserAddress(). An example code extract for use in the onRefreshMsg() is given below:
if( refreshMsg.hasPublisherId())
{
System.out.println("has PublisherId userId = "+ refreshMsg.publisherIdUserId()+
" userAddr = "+refreshMsg.publisherIdUserAddress());
}
RFA Consumer
The RFA Consumer examples use the GenericOMMParser utility class [Examples\com\reuters\rfa\example\utility\GenericOMMParser.java] and accessing the VPI information demonstrated in the method: parseMsg(OMMMsg msg, PrintStream ps, int tabLevel); as shown below:
The important point to note here is the check for the presence of the VPI information using the HAS_PUBLISHER_INFO flag before accessing the PublisherPrincipalIdentity within the message and which contains the VPI UserID and address.
Conclusion
By using the VPI feature on the Enterprise Platform, services can record who sent what price and at what time, ultimately providing the necessary information to support investigative work when the need arises.