Orion Advisor’s API: Using OData query syntax

OData query syntax is a standard way of querying RESTful APIs using a pre-defined syntax that allows the calling client to define the sort order, filter parameters and pages of data that is returned.  The full syntax can be found in section 5 of the OData Version 4.0 Part 2 specification.

Here are a few examples on the syntax use:

The $select option specifies a subset of properties to include in the response body.

  • /Portfolio/Accounts?hasValue=true&$select=Id,CurrentValue : Returns just the account id and the current account value.

 

The $top query option requests the number of items in the queried collection to be included in the result. The $skip query option requests the number of items in the queried collection that are to be skipped and not included in the result.

  • /Portfolio/Accounts?hasValue=true&$top=10&$skip=10Returns items 11>21

 

The $filter query option specifies an expression or function that must evaluate to true for a record to be returned in the collection.

  • /Portfolio/Accounts?hasValue=true&$filter=CurrentValue gt 0 : Returns all accounts greater than 0.
  • /Portfolio/Accounts?hasValue=true&$filter=IsActive eq false : Returns all inactive accounts.

 

The $orderby option sorts the results.

  • /Portfolio/Accounts?hasValue=true&$orderby=CurrentValue : Returns results sorted by current value in ascending order.

 

I hope this post shows that OData query options can be extremely powerful to supplement your api calls especially for optimization.

 

Orion Advisor’s API: Resource expansion

Several Orion API endpoints support resource expansion.  Resource expansion is a method to reduce the amount of API calls as well as the amount of traffic to and from the server.

An endpoint that supports an expand query parameter is

/Portfolio/Transactions/Verbose?status={status}&startDate={startDate}&endDate={endDate}&transTypeId[0]={transTypeId[0]}&transTypeId[1]={transTypeId[1]}&expand[0]={expand[0]}&expand[1]={expand[1]}

This endpoint returns all transactions that the signed-on user has access.  The available expansion options for this endpoint includes

  • None                                      0
  • Billing                                    1
  • Portfolio                                2
  • CostBasis                              4
  • AdditionalInformation      8
  • UserDefinedFields              16
  • EntityOptions                      32
  • All                                           63

For example, if you wanted all transaction for the month of July and include Portfolio and UserDefinedFields the call would look like

/Portfolio/Transactions/Verbose?startDate=07/01/2017&endDate=07/30/2017&expand=2&expand=16

The api help page has documentation for all the endpoints, and is helpful for discovering parameters the endpoints take, and the descriptions of those parameters.  It also shows which endpoints support resource expansion and expansion options.

 

Case Study: Asset Manager Analyst Tracker

An asset manager tracks the performance of each of their analyst’s stock recommendations for portfolio weighting throughout the year and currently this is being done via an excel spreadsheet and emails. This requires manual aggregation of the data that is time consuming and may be prone to errors.  The asset manager would like to automate this task as much as possible and has asked Suite3 to provide an application solution.  The main goals of the tracker application were to simplify the collection analyst recommendation, notify portfolio managers when recommendations are added or changed, and calculate a cumulative return for the analyst recommending.

Advent Geneva is utilized to calculate the analyst’s portfolio performance, which is aggregated by the tracker to calculate a cumulative total return for the analyst. Geneva is a real-time portfolio management, reporting and investor accounting solution designed to support complex alternative investment strategies.

The technology stack utilized to develop the portal includes:
VSTS, Asp.Net WebAPI, Angular 2, Typescript, Azure, Fusion Charts

We used Visual Studio Team Services (VSTS) for managing the Scrum project along with the Git source control features. By using VSTS, we were able to set-up continuous integration that made it easy to get the latest application version into a testable environment very quickly. The user interface of the application was built using Angular 2, written in Typescript. Angular gave us a framework to quickly create a single page application that provided a fast user experience to the end-user.   The user interface also used Fusion Charts to graphically show the many views of data in an easy-to-understand format.

The tracker supports analysts and portfolio managers. Portfolio managers see all current recommendations in one view with sorting and filtering.   The analysts see only their portfolio making it easy to maintain.

Some of the major features of the portal include:
▪ Model accounts are used to show current size and market price.
▪ Proxies can be used to enter recommendations on behalf of an analyst.
▪ The history of all recommendations is available for viewing at any time.
▪ Recommendation comments and conviction, as well as price targets are also maintained.
▪ Portfolio managers are notified by automated emails when recommendations are updated by the analyst.
▪ Graphical representation of the analyst performance is available for viewing.

Because of the tracker, the asset manager has an up-to-date view on how their analysts are performing through tables and charts. The communication between analysts and portfolio managers has been been streamlined and is providing timely actionable notifications in a more efficient manner.

Orion Advisor’s API: The Power of user defined fields.

Orion’s open architecture enables the sharing of information through their API.  When developing a custom application with the API user defined fields (UDFs) are extremely useful in many ways especially if you trying to avoid utilizing a database.  When you are creating a client portal and you do not want the weight of a database to store settings, UDFs may be a good alternative.  User Defined Fields or UDFs are custom fields that can be created at different levels including client/household, account, and transaction and different datatypes including boolean, string, date, time, and numeric.   The fields can be created and updated either through the API using the endpoints under /Settings/UserDefinedFields or the Orion app household overview.  Once the UDF is created and populated it can be utilized through several endpoints depending on the level of the UDF was set.

Let’s look at some real-world uses for UDFs at the client/household level.  The UDF values at the household level can be retrieved by using Portfolio/Clients/{ClientId} endpoint.

  • Turning features within your custom application on and off. Suppose there are screens that you only want to creating uses to see.  Then a boolean UDF could be created and either controlled through your application or Orion’s apps.
  • Integrating third-party application. Suppose you want to integrate Orion with another application and you need to store an authorization key before you can utilize the third-party application.  You could encrypt and store the key in a string UDF for a secure solution.
  • You could store user acknowledgements. Suppose you have certifications or terms of service and you need proof it had been seen by the user. A date UDF would do the trick.  Provide a checkbox in your custom application that would update the field with the current date.

These are just a few of the many uses of UDF at the household level, but what about other levels.  Suppose you or a third-party are loading transactions and there are values in the transaction that do not have a corresponding field in Orion.  UDFs can be created and populated at the transaction level and the values can be retrieved by /Portfolio/Transactions/{transaction}/UserDefinedFields endpoint.

In this post, I hope I demonstrated the power and possible uses of user defined fields to extend the functionality of Orion for your distinct purpose.

You can get more information from the Developers Getting Started Guide for the OrionApi here.

 

 

Creating an Angular 2 chart component with FusionCharts

I have used FusionCharts for both Angular 1 and Angular 2 projects and have been happy with the results.  FusionCharts is a comprehensive JavaScript charting library, with 90+ charts.

In this post I show how I created an Angular 2 chart component that depicts an investment analyst return line chart shown below.

This post assumes you have Angular 2 installed, you can get more information here.  You can download FusionCharts and the Angular 2 FusionCharts plug in here.  Once the plug in is downloaded follow the quick start to install and Import angular2-fusioncharts in the root @NgModule.

Now we are ready to create the chart component.  Components are the building blocks of any Angular 2 application. They are blocks of reusable code consisting of a view, and some logic.

Here’s the basis of our chart component:

import { Component, Input, OnInit, OnChanges } from ‘@angular/core’;
import { PerformanceService } from ‘./../services/performance.service’;
@Component({
selector: ‘return-chart’,
templateUrl: ‘return-chart.component.html’
})
export class ReturnChartComponent {
   dataSource: any;
   errorMessage: string;
   isBusy: boolean = false;
   returns: any;
   chartDef: any = {“paletteColors”: “#0075c2,#1aaf5d,#006400″,”bgcolor”: “#ffffff”,”labelDisplay”: “rotate”,”slantLabels”: “1”,};
  constructor(private performanceService: PerformanceService) {}
  @Input(‘inputData’) inputData: any;
   ngOnChanges(changes: any) {
        if (this.inputDat) {this.getData(this.inputData);}
   }
   getData(inputData: any): void {}
    createChartData(chartData: any, seriesName: string): void {}
}

If we look at what’s going on we first import needed modules and define the components properties selector and templateURL.  The selector is a css selector that identifies this component in a template and the templateUrl is a url to an external file containing a template for the view.

The Class method is where we add behavior and event bindings for the template.  Inside the class we first define needed variables, the chart definition could be kept in a separate file but since this component only job is to show the line chart I kept the definition with the component.

We now define the constructor injecting any needed services in our case the performance service.  We now need a way pass data into our component we can import the Input decorator from the Angular code, and decorate our property ‘inputData’.  The decorator tells angular to treat ‘inputData’ as an input binding.

We use the onChange lifecycle hook to detect any changes to ‘inputData’ and if it is changed to a non-null value getData is called passing ‘inputData’.  The getData() function will be dependent on your situation in my case I use a promise to call a services that calls a rest api to retrieve the requested data.

getData(inputData: any): void {
   if (inputData && inputData.id) {
      this.returns = null;
      var that = this;
      this.performanceService.getPerformanceData(inputData.id).subscribe(performance => {
      if (performance && performance.length > 0) {
              that.returns = performance;
              that.createChartData(performance, inputData.name);
       }
   },
   error => {
   that.errorMessage = ‘Error: GetData(): ‘ + <any>error;});
  }
}

Once the data is retrieved we are ready to format the data to be utilized by FusionChart to render the chart.

createChartData(chartData: any, seriesName: string): void {
      var ds = { chart: this.chartDef, categories: [], dataset: [] };
      var category: any = [];
      var series1: any = { seriesname: seriesName, data: [] };
      var series2: any = { seriesname: ‘Benchmark’, data: [], visible: ‘0’ };
      for (let item of chartData) {
             var tooltext = ‘Custom Tool Tip’;
              category.push({ label: moment(item.positionDate).format(‘MM/DD/YYYY’) });
              series1.data.push({ value: item.Return, tooltext: tooltext });
              series2.data.push({ value: item.bmReturn, tooltext: tooltext });
       }
      ds.categories.push({ category: category });
      ds.dataset.push(series);
      ds.dataset.push(series2);
      setTimeout(() => { this.dataSource = ds });
}

FusionChart  expects the datasource to be an object defined as { chart: {}, categories: [], dataset: [] }.  Where chart is the chart definition, categories are the date labels for the x axis and dataset contains the series of data.   The above function loops through the data to create the charts datasource.  There are many option that you can do to customize your chart one of which is a custom tooltip.  We use setTimout to trigger change detection.

We also need to update app.module to declare our component.

Now that we created the charts datasource it time to render the chart.

In the components definition, we defined the templateUrl as ‘return-chart.component.html’.

Inside this html file we have:

  <div id=”returnChart”>
                <fusioncharts width=”100%” height=”300″
                              type=”msline”
                              dataFormat=”json”
                              [dataSource]=dataSource>
                </fusioncharts>
   </div>

We create a div container make sure to set the element id so FusionChart can find where to render the chart.  The arguments we are passing include:

  • width and height: the chart dimensions
  • type: the type of chart we wish to create
  • dataFormat: the format of data passed to the dataSource option
  • dataSource: the configuration for the actual chart, as well as the data it should display

 

We have now created the chart component.  How do we utilize it?

<div id=”AnalystChart”><return-chart [inputData]=”analystData”></return-chart></div>

Using the defined selector we can drop this chart component any place you would like.

I hope this was informative and this is just the tip of the iceberg a lot more can be done using both Angular 2 and FusionCharts please refer to the documentation and see what you can do.

 

 

Case Study: Investment Advisor Client Portal

An Investment Advisor’s outdated approach to providing regular client updates on their investment portfolios began to lag their competitors, and clients continued to request a modern and more secure way for their important information to be tracked and communicated. In response, Suite3 LLC were engaged to develop a client portal that would enable them to provide a higher level of service to their clients.  The goals of the portal were simplicity, speed, security, and standout style and design.

The Orion platform is utilized to aggregate and homogenize data, which gives the Advisor the ability to swap out technologies with minimal disruption to the rest of their operation. The portal uses the Orion API which is a fully functional RESTful API for the Orion Portfolio Accounting System.  The API provides functionality for:  Retrieve, Update, and Create Portfolio records, and associated data.

The clients held-away assets are obtained via the Quovo’s Aggregation RESTful API, that provides the advisor methods for retrieving data from financial institutions on behalf of their clients.  Giving the advisor the ability to calculate a client’s true net worth, giving clients a 360-degree view of their wealth.

Using data from multiple data sources allows the Advisor to consume and provide data relating to their client accounts in a way that hasn’t been achievable before.  The Advisor will be able to see managed accounts, held-away accounts, sundry assets and private investments in one view and use this data to better advise and invest on behalf of their clients.

The technology stack utilized to develop the portal includes:

VSTS, Asp.Net WebAPI, SignalR, Angular, Typescript, Azure, Redis, Fusion Charts

Early on, we decided to use Visual Studio Team Services (VSTS) for managing the Scrum project along with the Git source control features.  By using VSTS, we were able to setup continuous integration that made it easy to get the latest application version into a testable environment very quickly.

The user interface of the application was built using Angular, written in TypeScript.  Angular gave us a framework to quickly create a single page application that provided a fast user experience to the end-user. The user interface also used Fusion Charts to graphically show the many views of data in an easy-to-understand format.

One of the unique challenges of the solution was to optimize the user interface communication with the end data providers in a way that would give the fastest user experience.  We accomplished this by using Asp.Net WebAPI’s to provide a business logic layer that naturally cut down the many calls to data providers.  This business layer also uses a Redis Cache for minimizing calls to the end data providers.

When features provided by the end data providers needed time to process, we utilized SignalR to push the data to the Angular application instead of making the user wait for a slow running process.

To provide faster response times, high availability and a failover capability, the portal utilizes Azure in multiple data centers.  This allows the data center closest to the user to respond as well as fail over to another data center in the case one would be offline.  The portal also uses the Azure App Service Environment protected by a web application firewall to protect the traffic coming into the application.

The portal supports advisors and clients.  Advisors can maintain configuration data for the application as well as have the ability to view data as the client user for any client that they support.  Clients see all their account data in one place. Including: balances, performance, allocation, detailed holdings information, as well as secure data sharing.

Some of the major features of the portal include:

  • Managed accounts and positions are displayed as drilldown charts grouped by accounts, asset categories, strategies, and risk categories and data tables that are exportable to Excel.
  • Incorporating Quovo’s Aggregation RESTful API gives the ability to provide the client and advisor access to held-away portfolios, giving the aggregated view of the overall financial picture.
  • The portal offers clients a competitive advantage of having a “personal balance sheet” that aggregates all their financial accounts into one view.
  • A fully functional info center where a client can receive custom alerts and commentary from the advisor, run Orion’s standard reports, and receive documents and statements.
  • The advisors can create custom grouping of accounts and positions for the client. This will give the client the ability to aggregate the account and position data by the newly defined custom group.
  • Individual support teams can be set-up for each client and be prominently displayed in the portal. The intent is to streamline communications and enhance collaboration between the client and members of the support team.

 

Because of the portal, the Advisor provides a higher level of service to their clients by unlocking data with rich graphics, interactive charts, and easy-to-read reports. Clients now have a single-source of their investment data, important documents and content provided by their advisor. For the advisor, there is now a window into the potential business opportunities through the review and analysis of a client’s total net worth via the personal balance sheet.  This results in both is increased business opportunities and service improvements through a better understanding of the client’s total net worth.

 

 

 

 

 

Steven Aronis saronis@suite3llc.com.

 

Introduction – Who Am I and Why Am I blogging

Hello, my name is Steven Aronis I am Entrepreneur, Architect, and a full-stack developer. I have extensive experience architecting, developing and supporting complex front and back office systems for major financial service’s institutions, hedge funds, and banks for over two decades.

I am currently a principal at Suite3 Group a provider of custom web development for financial services organizations.  Before that I was Chief Executive Officer and founder of Dataware Solutions where I established a highly successful professional IT product and services firm for more than a decade until its acquisition by FIS (previously SunGard).  After the acquisition by SunGard I became General Manager and Senior Vice President of Technology at FIS (previously SunGard) Protegent PTA business line.

In this blog, I am going to highlight some of my experiences past and present, any development techniques or patterns that I find useful, and anything else that I find interesting.  I have consulted with many financial services organizations of all sizes over the years and have learned a few things that I would like to pass on.  I hope you find it interesting.