Table of Contents

Date

10 Nov 2016

Attendees

Actions items from previous meetings

• Matthew Gardner: Review internally with Blackrock team re interest in early access to renderer framework
• Former user (Deleted) to find out who at JP Morgan manages the JP Morgan test pod, and let Afsheen know
• Former user (Deleted) to provide group with information on how the entity ML is passed into the renderer's iframe
  • Anyone interested can request a renderer example 1:1 from Former user (Deleted) which will demonstrate this
• Former user (Deleted) to provide group with documentation on the JIRA entity ML structure
  
  • Ideally this should be added to the type "registry" on Confluence
• Johan Sandersson schedule engineer for next meeting (2 weeks time) to discuss some of the technical details of how Factset's renderer works
• All: review capability and provide any feedback to their sales rep to ensure product management can properly prioritise enhancements to this feature

Agenda

Meeting notes

• Actions:
  
  • Blackrock interest in renderer framework - Matthew reached out internally and there was interest, but needs to follow up
  • Entity ML passed into renderer iframe - anyone interested can request renderer example code 1:1 from Bruce Skingle, which demonstrates this
  • JIRA entity ML structure:
    • Coming November 12th, in beta form
    • Has been asked not to share further details at this time
  • Johan scheduled an engineer for this meeting
  • All - please continue reviewing the renderer framework capability and providing feedback to your Symphony LLC sales reps
• Renderer demo from FactSet (introduction from Johan Sandersson, then Malay Shah will lead deep-dive):
  • Enhancers bot the replicates functionality that exists in FactSet workstation:
  • 
  • 
  • Our thinking was that this would be good to bring into Symphony, so that if users have a timely need for information as they chat - we (FactSet) can enrich their experience right in Symphony:
  • 
  • This gives exactly the same result we saw earlier, using the same method as we saw the answer in the workstation.  This is sent back as an object into the chat.
  • 
  • Clicking on it will open the FactSet workstation with richer functionality:
  • 
  • The interesting concept here is that we want this information to be sent as a message.  We don't want these renderers to be publicly available so that anyone can call our web service and get FactSet data.  We want the date to be controlled, sent by our bot, to a recognised user, so we retain control over our data.  And as people read back in the chat, we don't want to have to go and re-fetch information.  We want the information to be historical, at the time the user made the request.  The information is in the message, in the object structure.
  • Removal of FactSet app results in:
  • 
  • They key is that the information is in the message and we're just using renderers to display the information in a nice way.  Malay can discuss the technical details in more detail.
  • Bruce: if anyone has specific questions, please ask them.  In the absence of questions, Malay can you give us a summary, what was easy, where the challenges were, etc.?
  • Malay: one of the key areas that we focused on during development was to make this fast and responsive.  A lot of our decisions about how to design this were focused around that.  One of the first challenges we had was we didn't want to make a request after the message came in to our backend to fetch all the information you see here.  This is for both performance reasons and for access to the data.  The calls to the back end are unauthenticated.  So one of the challenges was how do we pass through information from the extensions API to the backend.  We have a renderer URL and we add a fragment to the end of it (an id) and when the renderer page is rendered it calls back to the controller of the extension app with that id to get the data.  There's a lot of boilerplate code to get the entity into the renderer from the extension app.  This was one of the key challenges.  We ended up with a different approach than what was recommended in our discussions with Symphony.  A simplified API to pass the entity from the extension into the page would be welcome, but there are ways to do that that aren't terribly difficult.
  • One of the other things we did to make this responsive was leverage caching (particularly browser caching) as much as possible.  We discovered that the framework tacks on query string parameters to the renderer urls that defeat browser caching, but I believe the Symphony team is working on removing that so that browser caching can be used.  Another interesting issue we've run into with building the renderer is using common web libraries like angular that are cacheable, but because it's in iframe those libraries need to be processed in each iframe.  Given the number of libraries we've used, this takes up to a second to load.  We're looking at pre-loading the libraries in these iframes to optimise response time.
  • Bruce: so I assume that these details are things you've discussed with the platform team?
  • Malay: yes - they're aware of all of these issues and ideas.
  • Malay: Building a mapping on the back end between Symphony accounts & FactSet accounts was interesting.  The data you see here is somewhat personalised to the user, and so these values may differ between users with different preferences or subscriptions.
  • Bruce: you mentioned unauthenticated calls - is this due to insufficient user information in the calls we make to you?
  • Malay: yes we don't have that information yet.  We also don't want to load the content at rendering time and so we're putting it into the entity object itself, and we're doing the authentication on the backend when we get the entity id.  From that we can get the user identifier and then impersonate that user to get their personal information
  • Matthew: how do you get the identity of the user?
  • Malay: the symphony user account is part of the message that comes through..  We have a map of symphony ids to FactSet ids which we're still working on.  From the Symphony app when you're logged in there, then subsequently logged in to FactSet we'll match the accounts up.
  • Matthew: are the symphony user ids unique across pods?
  • Bruce: yes there's a prefix that's allocated based on the pod id.
  • Bruce: the email addresses are reasonably reliable because the pod will ensure that no two users have the same email address within the pod, and the domain names for which email addresses are allowed are configured per pod.  So it should be the case that we wouldn't get the same email address in different pods.  Though there are corner cases with the public pod.
  • Malay: originally we thought about doing a reverse lookup of the email address from the user id then get the FactSet user from the email address, but there are corner cases which led us to not do that.
  • Johan: this answers object is fairly FactSet specific, but if another app wants to render our object that is technically possible.
  • Bruce: would you be willing to publish the definition of that, on the WG confluence site?
  • Johan: I think we'll be willing to share the chart, once we're done.
  • Bruce: from my POV it would be great if whatever you're willing to share is shared on the WG wiki pages, as real examples of what real partners and customers are doing.
  • Peter M: how does SAML factor into the user mapping piece, if at all?
  • Malay: it doesn't - we trust the Symphony authentication model and use the Symphony's id to do our user impersonation.
  • Peter: and SSO?
  • Malay: there's been some discussion around authentication within the iframe, but basically we can get a trusted identity from the Symphony app to the extension so it's SAML-like.  It would work for web requests as well.
  • Bruce: it's fair to say this is a complicated conversation and the considerations aren't only technology related.  You may not want to share all of the user information you have.  We may have to work our way towards figuring out the level of information we provide without leaking other information the customer wishes we hadn't.  It is sometimes a more complex conversation than when you first start out.  As I said last time, the functionality that's being released has been release to support specific capabilities and there are general capabilities (like lifecycle events, opening and closing renderers) that you would expect to be there in a production ready API, but it's not all there yet.  Product management prioritisation has been to release specific integrations, and what we're releasing is in support of that.
  • Johan: just to clarify, the rendering here doesn't happen because I have the workstation open - it happens independently in Symphony.
  • Bruce: I think that brings it to a close.
• AOB:
  • In two weeks time it will be Thanksgiving in the US, so our next meeting will be December 8th.  I'll cancel the invite after this meeting.

Action items

• Johan Sandersson: review internally if/when to publish the FactSet "chart" and/or "answer" entity definitions to the type "registry" on Confluence
• Former user (Deleted): cancel the next meeting (due to Thanksgiving)