DFUs for Batch Access

Using Data Feed User accounts for batch access

From February 2017, the recommended and officially supported method of accessing Web API data in “batch mode” is via Data Feed User accounts.

From June 2017, the ability for normal (aka interactive) users to create their own batch authorizations via the StatPro Revolution API Authorization Management website has been removed. (And from May 2019, the website as a whole was deprecated.) Existing batch authorizations for such users will still work, but new ones can’t be created.

Read this page to find out about Data Feed Users, how they are set up for Web API batch access, and how to migrate existing batch authorizations to the new way of working.

What are Data Feed User accounts?

Data Feed Users are accounts with no password and no security question. By design, they cannot be used to interactively log in to any Revolution website. They are designed to be used for FTP-related data import, batch-mode data export, and for owning benchmarks that are calculated by the StatPro Benchmark Manager. They may find other uses within Revolution in the future.

A Data Feed User account can be thought of as a form of officially-supported shared user account. Shared user accounts with email addresses such as revbatchaccess@mycompany.com are problematic because:-

  • they are shared by multiple interactive users, all of whom need to remember the password and security question
  • they can lead to multiple, simultaneous logins by the same user account
  • actions performed by these accounts are not attributable to any one person
  • they are inherently incompatible with modern Information Security (InfoSec) policies.

Using Data Feed User accounts instead of shared, interactive user accounts solves all of these problems.

An individual Data Feed User (DFU) account is created by StatPro’s Client Services team, and is intrinsically linked to a specific tenancy. The tenancy may have a number of different DFUs, each used for a different purpose - one for data import, one for data export, and so on. A DFU cannot become a member of additional, alternative tenancies.

StatPro Client Services should be contacted by tenancy owners (aka local administrators) whenever DFUs need to be created, set up for Web API batch access, renamed, disabled, deleted and more.

How Data Feed User accounts are set up for Web API batch access

A DFU account is used for Web API batch data access as follows:-

  • StatPro Client Services create the DFU account (if not already created)
  • the DFU needs to have access to the portfolios (and other Revolution Analytics data) whose data it will export in batch mode from the Web API; therefore it needs to own these portfolios - or - the portfolios need to be shared with the DFU account by the users who own them. These two approaches may be combined:- the DFU may own some portfolios, and have access to others via sharing.
  • for a particular batch application - e.g. Revolution-i’s Batch module - StatPro Client Services create a long-lasting “batch authorization” that is externally represented by the combination of the DFU’s email address and an Application-Specific Password (ASP)
  • on creation of the batch authorization, StatPro Client Services send an email with the DFU’s email address and the ASP to one or more tenancy owners (aka local administrators), with instructions for setting up the indicated batch application with this information
  • the batch application is set up (configured) with DFU’s email address and ASP in a way that is long-lasting
  • the batch application can then be run unattended.

For help and support with any of the above steps, please contact StatPro Client Services.

How batch access worked previously, and why it was problematic

Previously, normal users would have to log in to the StatPro Revolution API Authorization Management website (now deprecated), and manually create a batch authorization for each batch application that they used. The resulting Application Specific Password (ASP) - plus the user’s email address - would then have to be entered into the batch application in question.

The problems with this approach are:-

  • batch access should be long-lasting, but if a user left the organization and their account was disabled or deleted, or if the user changed their email address, then batch access using their account would stop working
  • the process was too manual, and required individual users to do too much work
  • these problems could lead to batch access being performed by shared user accounts, used by many users but unattributable to any one person. (See section What are Data Feed User accounts? above for reasons why shared user accounts are problematic.)

Support for batch access by normal users

Batch access by normal (i.e. non-DFU) users is deprecated as of February 2017. As June 2017, new batch authorizations cannot be created by normal users. Existing batch authorizations for normal users will still work, but may be terminated at some point in the future (at this time we don’t have a date for this cut-off).

Migrating batch access to Data Feed Users

Migration of an existing batch authorization - by a normal, non-DFU account - should be done at a time when the application is not being used (i.e. when batch access is not being performed).

Contact StatPro Client Services to perform the steps outlined in section How Data Feed User accounts are set up for Web API batch access above. When batch access is working correctly using a DFU account, remove the original batch authorization (email address + ASP) from the configuration of the batch application in question.

(With the deprecation of the StatPro Revolution API Authorization Management website, the original batch authorization can no longer be revoked and should be considered to be orphaned.)

Advice for client application developers

Client applications can prompt tenancy owners (aka local administrators) to contact StatPro Client Services and ask them to set up Data Feed User accounts for Web API batch access.

Last updated: March 2019