Table of Contents

Date

30 Mar 2017

Attendees

Actions items from previous meetings

• Former user (Deleted): reach out to Former user (Deleted) about finding someone from Morgan Stanley to participate in REST API standards subgroup.
• Former user (Deleted): work with Peter Monks and Maurizio Pillitu to contribute API example code to Symphony Java Sample Bots repository.
• Former user (Deleted): talk to Matt Joyce (Deactivated) and Former user (Deleted) about starting a subgroup re: consistency in API implementations across languages (.NET, Java, and Python).
• Johan Sandersson: send a couple of example use cases to the mailing list to give others an idea of the structure and level of detail he's looking for.

Agenda

Meeting notes

• On-Behalf-Of Demo

  • Anjana Dasu (AD): OBO functionality allows you to create conversations and connections, as well as own presence from another system. All integrations require an OBO app to be enabled by the customer on their pod and for specific users. These apps perform an auth sequence that’s different from bot auth.

  • Leslie Spiro (LS): Are the apps deployed on servers or desktop or both?

  • AD: App is basically just a shell –

  • Dov Katz (DK): So this is a process, is that correct? Is it running on the desktop or as a process somewhere on the server?

  • AD: It doesn’t matter necessarily. So the way it’s manifested within Symphony is that there’s an app kind of like a shell with a name and an ID matching the app, and that app authenticates using one of our endpoints for app authentication. You’ll get back an app token that you can use to authenticate and act on behalf of a particular user. This user must have the OBO app enabled. Once you’ve done that you can call specific endpoints – they’re different from bot endpoints – which will enable the app to access essentially the same functionality as a bot, but you can pass only the session token (do not need to pass key manager token).

  • Peter Monks (PM): Why a different set of endpoints?

  • AD: Because bot endpoints require the key manager token and OBO endpoints do not.

  • DK: Are the new endpoints backward compatible or are they forks?

  • AD: They’re forks.

  • PM: That’s going to make it difficult for the client SDK developers, because it doubles what they have to support. In a future version might be good to consolidate endpoints to make downstream implementation easier.

  • DK: Or make it so that bots and OBO apps use the same endpoint with different headers.

  • PM: Yeah, exactly.

  • AD: Yeah, for our pod-based endpoints we have done that. For example, if you want to get a particular user’s presence via a bot, that endpoint only takes in the session token, so we use the same endpoint. But feedback received, I understand your concerns.

  • LS: Can our application, say, create a chatroom and invite people from the user’s address book into that chatroom using OBO?

  • AD: Right now you can create multiparty chats and connections, but not chatrooms. The chatroom would have to be pre-existing. This is because, according to the current functionality, if you have the ability to create chatrooms as a user, then you get access to all of the user’s chatrooms at that point. That would create problems so right now we don’t permit that.

  • DK: Can an app have a user’s identity? E.g., can the research desk create messages on behalf of Joe User.

  • LS: Here’s another use case: we’d like to use the app to create a chatroom and send a request for quote.

  • AD: In those types of use cases, you’d want a bot user…

  • LS: No, you don’t. We’ve tried this, but we’re getting massive pushback from salesmen, saying it absolutely needs to be on behalf of real people.

  • AD: What I’m saying is that if you want to create chatrooms, etc., you could do that with the bot. Then to have the RFQ come from a user you would use OBO.

  • Johan Sandersson (JS): Let’s say we have two users from Company A and B. FactSet’s pod is not even involved in the conversation between these users. So we need OBO to connect directly to the pods of these users. So I can see from your perspective that if you want a user from Company A to set up a chatroom, that has to happen on the user’s pod. Is that applicable to your use case?

  • LS: Yes, it would be nice for OBO to allow the app to create a chatroom just to keep the messages in their own space. But having the bot do it works for us.

  • Paul Teyssier (PT): Anjana, do you want to talk about where we’re going with permissions real quick?

  • AD: In the future, we may allow the app to have permissions to create chatrooms and add people to the chatroom. In that case, the app would have only restricted access to a user’s chatrooms, etc., rather than the unrestricted access it would have if we enabled this now.

  • AD: I want to run a simple demo. And after that, Johan, if you have a screenshot of FactSet’s integration, it might be good to show people that.

  • AD: Here’s the app we’ve written and here’s the chatroom I’ve created for for OBO testing. Note the user and chatroom IDs. I’ve set up an app that talks to a customer pod, taking a user, chatroom id, and message text as parameters. I’ll run the program and the message will get sent into Symphony as coming from my user. The app has a certificate that is installed on the customer pod. Johan, can you show a screenshot from your app?

  • JS: Yes. Our use case involves user A from Company A (with their own Symphony installation) and user B from Company B (with their Symphony installation). FactSet as a Symphony client is actually not involved at all and should not be in this case. 

    • When the user A is in his FactSet – we are connecting him directly to his Symphony pod. 

    • If a client has all security components on-prem then traffic from the installed FactSet will also be on-prem and never reach internet unencrypted. 

    • The reason for using OBO here is that we should not have “full” agent API access and handle the clients’ certificates and so on. 

    • OBO allows the pod admin to specify which users should be exposed and FactSet can then do certain actions on-behalf-of such a user. 

  • JS: As an example – user B is the author of a research report available in FactSet, when user A reads this report he can see that user B is online and send a message directly from FactSet and only go to his Symphony application once user B replies.

  • DK: Why not put these side-by-side like in Skype?

  • JS: We don’t want to change the way the user uses Symphony. For example, if they’re running Symphony in a custom container, we want to allow them to continue doing so but still have their FactSet workstation be Symphony-enabled.

  • DK: Symphony folks, do you intend to create a service on the desktop to integrate with desktop apps?

  • PT: We don’t know if we’ll continue to invest in that capability or just handle this via OBO because this is very complicated to do given that we don’t know what’s happening in a given customer’s environment.

  • Peter Leong: When is this available? The OBO API?

  • AD: This will be available at the end of H1 for customers and partners.

  • PL: So we won’t be able to play with this next week at the Foundation hackathon?

  • AD: No.

  • AF: Anything else before Anjana drops? 

  • Paul, next is an update from you on Language Bindings. Can you do that?

  • PT: First I want Dan to give a Demo…

  • Dan Nathanson: I don’t think I can – it’s not running. Ping me again at the end.

• Language Bindings Consistency

  • PT: Ok, thanks. Just a bit on language bindings. We said we’d focus on REST standards and use cases. There are many groups working on language bindings and we’ve been trying to figure out how best to support their work. I put together a quick draft recommendation for people working on new language bindings. I’ll share that at the end of this call. If you could give input between now and the next meeting, that would be great.

  • Aaron Williamson (AW): Can you put it on Confluence?

  • PT: Yes, I’ll do that. I’ve been working with a few of the early projects, especially Frank, on this. We haven’t fully incorporated their feedback, but we’re working on it. I see this as an opportunity for those projects to share best practices for those who come along later. Johan, please point Malay to this.

  • JS: I will.

• API Design Guidelines and Best Practices

  • AF: I’ll have a draft API Design Guidelines and Best Practices document ready for people to take a first pass at soon, for continuity and making sure there are no obvious gaps. I’ll send an update when I have that.

  • DK: I owe you a response.

  • AF: No problem. Anybody have questions?

  • LS: I have a quick plug. Paul was talking earlier about the desktop API for interactions between Symphony and other apps. Our product Glue is exactly that, a desktop bus for connecting apps.

  • DK: Ok, cool, we’ll send some mail to follow up on some of this, as well as on the Design Guidelines question.

• Use Cases

  • AF: Johan, do you have a few minutes to give an update on your use case work?

  • JS: Not much to report. Paul and I had a catch-up and talk about how to structure them. I think the last action was for Paul to have an internal discussion at Symphony.

  • PT: Yes, that’s still the case. It’s a slow-burn approach because there’s a lot going on in this WG and others. It’s still very relevant, but I think we’ll continue to progress only as quickly as team members are able?

  • AW: If there are other WG members with capacity, is there anything they can do to help progress this more quickly?

  • JS: Yes, easiest part is to go into the examples page on the wiki and plug in all the use cases that haven’t been touched on before. Even if it’s just one-liners. That would be really helpful to get a broad sense of what the group is thinking in terms of use cases. I’m happy to reach out to people help structure those as we need them.

  • PT: Please pick use cases that are as close as possible to projects you actually want to start and work on, so we can spend our collective energy on helping you progress something real.

  • JS: Yes, good point.

• Symphony Java Sample Bots Code

  • AF: Dov, you had an action item about contributing sample code?

  • DK: Yes, this was a wrapper around the Java code to make it easy to set up and deploy bots. I’m struggling to find a clean API for creating bots and we’ve done that, but we don’t want to be in that business, so I’m wondering if others have found an open source project they like for that. And if not, I’d love to talk about open sourcing ours. [Peter Monks suggests looking at http://www.botmill.io/]

  • PM: I think BNY submitted something similar at our last hackathon…

  • PL: We let that languish since I had other things to work on, but that’s what it was for – using NodeJS and NodeRed to create a GUI to create and deploy bots. I’m working on something similar, not based on that code, and we can talk about working together on that.

  • DK: Yeah, as much as I love Node I’m stuck using Java for a lot of things, so I’d love to offload our code somewhere we can all use it.

  • Matt Joyce: I was working on this on the Python side and building a framework is difficult unless you know what the eventing model is going to be. You might want to look at Symphony Interconnect, which allows you to do this as a message queue.

  • DK: We looked at that – it gets complicated with the identity of the Symphony bot, but maybe OBO can help with that. If anyone’s interested, I’m happy to share what we did even before I’m able to share code.

  • Frank Tarsillo: I’m definitely interested in hearing what the limitations were with the SJC.

  • DK: I built on that so I’m definitely very familiar.

  • FT: What are we talking about specifically?

  • DK: There are message listeners at different levels and it’s not clear you need to listen on one v. the other. There are too many places you can add listeners and get too much back. And other places where interacting with the message payload leave a bit to be desired

  • PT: We at Symphony would love to hear how to make it easier to deploy these and go to market and how we can help.

• Symphony Java Client Update

  • FT: I think it’s great to hear about use cases like Dov’s – getting that information out there helps everyone. On the SJC, everyone’s hopefully seen the version 1.0 that I put out. It’s basically production code, fairly stable – we use it every day. The most important thing we need to do is document better what’s there. I’ve created a wiki page off the main project Github, so please look at that. It’s not complete but we’ve put a lot up and will continue to document.

  • Where we’re going with it next is to improve performance. Anytime a chat conversation object gets created, we populate all the profile information of the participants dynamically. That’s performing poorly, so we’re going to put in a lazy cache. The next part is focusing on the AI framework, so that if you like the hubot style, there should be a framework for that. We want to make it super easy to create listeners that parse that. There’s more work to be done in the parser, we’ve found errors there. I think Bruce Skingle offered to donate his parser, so we should discuss that.

  • PT: I can work on that.

  • FT: We’re not streaming presence through the client by default anymore, you have to turn it on in the service. We have that issue open with Symphony LLC. Firehose we pulled out – there was concern about implementing that because of pod stability issues and Symphony said they wouldn’t support it. We have integration testing now—every time we commit, it tests end-to-end messaging between two bots on the Foundation pod. Unit testing is light, but trying to get to 75% coverage. I’m looking for community feedback, as always. Oh, there’s also a lot of reconnect and reauth logic in there, and I’d love to hear feedback, especially from DK, about how that’s working.

  • DK: Yeah, I’ll try to reproduce the error I’m seeing and share it with you.

  • FT: I think longterm I want you to be able to create a bot in one minute and hand it off.

Action items

• Former user (Deleted): Add draft API Design Guidelines and Best Practices document to Confluence and send link to mailing list.
• Former user (Deleted):
  • Talk to Former user (Deleted) about contributing his MessageML parser for use by Former user (Deleted) in the Symphony Java Client.
  • Add draft language bindings recommendations to Confluence and circulate link via mailing list.
  • Progress conversation within Symphony about how to structure use cases.
• Former user (Deleted):
  • Reproduce the deauthentication(?) error encountered using SJC and send information to Former user (Deleted)
  • Talk to Former user (Deleted) about functionality needed from SJC to support Morgan Stanley's bot-deployment needs
• Former user (Deleted):
  
  • Talk to Former user (Deleted) about bot deployment work, possibly contributing to Foundation.
• All members: 
  • Contribute example use cases in the wiki.
  • Send feedback to Former user (Deleted) on draft recommendations. (Especially Former user (Deleted), Matt Joyce (Deactivated), Former user (Deleted).)
  • If you are aware of an open source project that provides a good API for creating bots, tell Former user (Deleted).