Table of Contents

Date

18 Jan 2018

Agenda

Action items

Add new action items here.

Attendees

Meeting notes

Jon Freedman: Trying to get more participation in other language APIs, e.g. JavaScript. I've written part of an API for all the calls I need, but I've been in conversation with Symphony employees and they've said they're going to write one but that was over 12 months ago.

Peter Monks: Yeah, Glenn's been working on one but he's in very high demand at Symphony and hasn't been able to get to it. There's another lady named Susan Hamit(?)...

Jon: Yeah, she wanted to use a node API. I've always hoped Symphony would recognize the value of their employees working on this kind of thing.

Johan Sandersson: Is there any representation from Symphony LLC on this list?

AW: No.

Frank: That's unfortunate. Wasn't Dan Nathanson the Symphony rep in this group?

PM: Yes but it's their board meeting today and I know he's very busy.

FT: Ok, so for people who didn't join the call last week, we did discuss a few things. I published the repo for Symphony-by-Example to document some of the SJC. But it's not my project, it's everyone's, so please contribute your API use cases and examples. If you don't know how the repo is assembled, just send me an email and I'll spend some time with you on how to create the navigation and structure. Any questions?

PM: This is more of a documentation project, not intended to be code snippets or examples, right?

FT: It can include snippets, but we recommend that existing examples just be linked to from the source documentation, to keep the examples whole. What I did for SJC was publish a code snippet to give the reader some satisfaction, but we'd expect contributors to link to the context, and maybe include small snippets to illustrate.

Here are links to the repo and the website. So you can very simply add your own subsections with navigation. I wouldn't suggest putting actual code in the repo, just pointing to where it exists in an actual project.

Next thing we discussed, with Dov, was the extensions API. Leslie from Tick42 presented something through email about hte need for that API to provide a means to publish messages directly to the container. So if you're interacting with an app and want to send a message  to the Symphony bus, you should be able to use the container and its transport rather than going to a backend API. With the absence of the LLC on these calls, we could potentially create a very lightweight internal gateway, especially for Symphony applications in the container, where you send an OBO message to an agent sitting in your network that publishes that into Symphony. And Dov sent some code to illustrate how easy it would be to do with the SJC and we agreed that we should put together a proof of concept.

Could there be a bus sitting between the Symphony module and the container? That was one idea. But the need to have modules that leverage Symphony using native/local connectivity to support those interactions is clear. I'm curious if anyone's seen Leslie's proposal and has thoughts on that. I'd like to progress that and get something out there.

JS: Yes, it falls within the kind of thing we want to do, from a product manager standpoint, but I haven't been able to delve into the technology piece.

PM: I reviewed it but don't recall the details.

Jon: I read it, but that's not how we use Symphony so I don't have a strong opinion either way.

FT: Yeah, and what was nice about this request is that it hits the extensions API bit but also lines up with the DWAPI WG's mission, since it will mean creating an adapter to facilitate this in the container. It's crazy how you do it today–the application module has to relay it to the app server which creates a message to a bot or agent server which then routes it back into the network. So it's a lot to do something simple, and doing it natively would be much simpler. 

Simply put, I'm probably going to put something together in the next couple of weeks. Dov gave me some code for it and it's pretty simple. And if everyone agreed with doing things this way, there would be a conversation with Symphony about whether they see value in the design pattern and maybe putting it on their roadmap. I assume that's agreeable to everyone?

JS: Yes. Frank, do you remember the old Paragon bus?

FT: Yes.

JS: That was able to take the message in locally and then post it to the Symphony web applications running within Paragon, right?

FT: Is that right? I know they could do intents on the Symphony side to perform an action, but I didn't think it was sending a message, just starting a conversation or bringing up a window.

JS: No, you could send messages as well. And I think it must have called some JS function within the Symphony application.

FT: Agreed, but I'm not comfortable saying they could support message transfer. I'll send a message to Lawrence and see. But I think it's not supported today.

JS: Yes, but I think it's still supported with Paragon. But if there's an endpoint in the webapp that supports that for Paragon, you should be able to use it through another container.

FT: I hear you and agree. I know that configuration was messy in Paragon, but I take your point that the interface might still exist. James Turck might know, actually. I'll ask.

JS: But yes, there could be reasons that Symphony wants to remove the endpoint.

FT: But for what we're talking about, with the OBO gateway, it gets around all of that because you have the keys so you're just sending a REST call and the rest is taken care of. In the end, you can put a method in the container giving you access to that.

JS: Would you pick out the session and key manager tokens separately and use those in the push to the agent?

FT: In the OBO workflow, if you apply the application in the Symphony LLC that represents the OBO user (the gateway) then the key that the module creates is the application itself, and it gets sent with the message to the gateway which will generate a session key with the application key to send the message.

JS: So it needs to be a trusted application.

FT: Yes. There's two parts: the application module itself (with the business logic) and an application that is the OBO gateway that the user would have to add to be able to send messages from the application through the gateway.

JS: Some clients are having trouble with the concept of FactSet's app being in the circle of trust but outside the firewall.

FT: Yeah, when they came out with the circle of trust, there was a lot of conversation about the approach and the difficulty of integrating it with external applications. And Symphony didn't really take those concerns into account. They should have followed a basic OAuth approach, which SAML more or less follows, and the SP should be able to redirect to an IDP or application service and share the keys. The customer with SSO enabled with Symphony should be redirected back to the FactSet SP and that redirection (SP-to-SP), you share the assertion between the two because the customer's already authenticated with Symphony, and that assertion can be forwarded to FactSet and the user authorized that way. And I don't think they followed that approach and I think we're seeing the problems with that. 

That said, we're still going to build this thing, which will get around that. And then we'll demonstrate it and take it from there. Other than that, I encourage everyone to go back to education and use cases, etc. – getting the great work we're all doing on the different language bindings out to a wider audience. There are a lot of business people who don't understand the value of Symphony or the Foundation's work around open source and the consistency of the APIs. And the use cases can help with that. Matt Joyce just published his initial work on the Python bindings, which I think are following that. 

Anybody else have use cases they'd like to explore? It would be nice to ask Dan to present the roadmap on the APIs, especially the REST API, because I've seen nothing from them in a long time. Anybody have concerns with that? Good use of our time?

PM: I actually had a brief conversation with Vincent Gurle yesterday, the PM of that team, and he hinted at some exciting updates, so maybe we can get him in?

FT: Yeah, absolutely. Could you help arrange that?

PM: No problem.

FT: Anything else? Anyone? Can I ask a simple question, what does the dev cycle look like, if you can say, at your firms? How many Symphony-related projects do you have in your pipeline? Are people bringing bots or apps to production this year?

JS: We have pieces in production and are rolling it out to clients, with a trusted app, with bots, obo, etc. We're also adding more bots and more application functionality that use the existing OBO functionality. Deeper integration.

WQ: I guess we're looking at internal use cases around content sharing, notifications with the REST API, working through the trade lifecycle.

FT: And you're getting at the root of the question, which is what are your use cases? Is there anything you'd like to see? I haven't seen anyone doing things with business workflows, like tying into ticketing systems over the network.

JS: We're working with Symphony on being able to send content into Symphony based on a user. So you first pick the content, then you go into Symphony and pick the distribution groups, etc. – we want that to work so we don't have to deal with issues like "you can't send this content to these users because of these restrictions." We want to invoke the blast dialog in Symphony with content from outside. That's something we need them to build. Call it a "blast stream" you get via the API, and when you open the dialogue the valid users are there and you can send the content out.

FT: Anyone else?

PM: Late last year, we developed a bot that integrates with GitHub, so DB could do basic manipulation of GitHub issues without being able to use the GitHub web interface. It's an MVP, but it's open source and contributions are welcome.

FT: That's a great project, though I don't think it represents a new use case.

PM: And I think that we're seeing that using Symphony as a command line for other systems is not a bad model, so I think there's a pattern there.

FT: Ok, that's all I had. There's definitely a drive toward use case documentation & showing our wares. So please help there. And then there's how we innovate around Symphony's limitations. Again, chip in if you can. And the other part is, on the bindings themselves, we're listing out all the different language bindings. What we haven't done is map out the different types of language binding calls across the different languages, so we can see what the coverage of the bindings is. That makes it easier for new users to see at a glance how things work. So it would be great to see contributions there as well. Any if anyone has other things they'd like to discuss, please speak up.

PM: I have one other item, which is that Symphony has just enabled multifirm chat rooms in the production pods, which is exciting. It's controlled by user entitlement, so your admin has to turn it on per-user. So please ask if you can have that turned on for you, because we'd like to have a chatroom for the Working Group, but each of you would have to be enabled.

JS: I'm ready!

FT: I'm in, obviously, but people like Will may have issues with the corporate compliance structures.

JF: I'll check with our compliance guys. 

PM: My recollection from talking to Mike Harmon is that there are limitations but they hope to lift those as time goes on.