Table of Contents

Date

26 Jul 2017

Actions items from previous meetings

•  Lynn Neir (Deactivated)onathan Christensen: provide rough timeline for release/pre-release of the HTML5 app revisions; continue to update the WG as information becomes available.
•  Lynn Neir (Deactivated)onathan Christensen: inform the WG whether the LLC pre-release the HTML5 app on the SSF Open Developer Platform.
•  Lynn Neir (Deactivated)onathan Christensen: confirm that Symphony intends to open-source the HTML5 app and provide a rough timeline.
•  Lynn Neir (Deactivated)onathan Christensen: provide an official statement of the LLC position on enabling the UI to run in alternative containers, and how such third-party containers would be supported.
  
•  All: If your organization is interested in seeing Symphony support DB's Plexus interbank interop framework, tell Jonathan Christensen.
•  Lynn Neir (Deactivated) and All: Review Tick42's proposal for a container API specification, including Leslie's email to the list and Kiril's pull request (especially the TypeScript specification), and comment on the mailing list.
•  Former user (Deleted) and Leslie Spiro: follow up with Lynn Neir (Deactivated) to discuss Symphony LLC's strategy regarding Symphony Electron desktop interop/on-behalf-of functionality.
•  Lynn Neir (Deactivated): test Container.JS with Symphony Electron if possible
•  Lynn Neir (Deactivated): add file download API method (and any other planned methods) to list in Confluence
•  

  JC & Lynn Neir (Deactivated): check whether documentation of Symphony web app API is accessible

•  JC & Lynn Neir (Deactivated): let WG members know whether the API methods used by Symphony Electron are exposed in Symphony 1.46
•  

  Aaron Williamson: send ODP info to list (esp. to Former user (Deleted) & Former user (Deleted)) 

•  

  Aaron Williamson: arrange meetings between member firms and DB re: interest in Plexus

Meeting notes

Maurizio Pillitu: Documentation for the ODP is available in Confluence. The ODP is a set of online services and best practices to improve the productivity of a Foundation project team. It’s open to new Foundation project contributors, existing project committers, and hackathon attendees. Hackaton access is temporary to the hackathon. We’re having the Innovate 2017 hackathon in New York on October 4^th, and I’m happy to share more info later on.

The core of ODP is the project infrastructure, which is everything necessary to produce secure, compliance software throughout the lifecycle. It provides access to the Symphony API for development and testing purposes. The infrastructure binds to the project lifecycle, from incubating, to active, to archived. At each step of development, we provide both tools and best practices.

For hosting, we use github.com, and all Foundation projects are hosted under the Github domain. This is the only part of the infrastructure that offers no choice. The next step is building, and there we don’t have any requirements. We’ve had good feedback on options for continuous integration, including that MyGet works well with .NET and C#, so we offer that as well as Travis CI.

The next step is reporting, and we don’t impose any requirements there, we just give project maintainers options that they can choose depending on what they’re interested. They’re divisible into legal, security, and quality reporting. For example, for legal compliance we have FOSSA, WhiteSource, and VersionEye. And for the other categories we support a number of services.

The next step is to publish the built artifacts into public repositories. We integrate with the most important public repositories, such as Maven Central.

Finally, we can deploy the artifacts to a containerized environment running on OpenShift. This is the connection between continuous integration and the Foundation developer pod. The end result is an end-to-end pipeline with an easy way to access automation supported by the foundation that provides a lot of immediate advantages to the developer as well as peace of mind for compliance officers and the like.

I want to touch quickly on the future of the ODP and the past. Until now, the ODP has been reactive to the needs of projects. So we’ve onboarded projects like the SJC, and we added systems to make our product automation better. In the future, we’d like to be more proactive, by getting in touch with members to open a discussion and understand how to expand the ODP to be the set of tools and best practices that members and projects want to use.

I’ll show you an example of a project using the ODP, the Symphony Java Client, to show what systems it uses. The first is CI & testing using TravisCI. Everytime the code gets built, there are unit and integration tests run against foundation.symphony.com. VersionEye checks for common vulnerabilities and also for non-compliant licenses. It also uses Sonarcube, to scan for security and test coverage. All of these systems are a great way of understanding the quality of your code, and to report back to ESCo to apply for project activation. The last feature I want to show is that if you search Maven Central for symphonyoss, you’ll see that the SJC artifact has been deployed here.

Real quickly I also want to show you the REST API client. It uses .NET, and this demonstrates that the ODP is intended to give you access to all of these features regardless of what technology your project depends on. You can see that we’ve integrated the REST API client’s development process with VersionEye and MyGet.

That’s pretty much it. I hope it’s a good overview. I’m happy to answer any questions and any doubts, as well as to open a wider conversation about which parts of the ODP you can use, which you may want to see in the future. And that’s it.

Aaron Williamson: Ok, get in touch with Mao if you have questions or would like access. Nick?

Nick Kolba: I sent out an email to the group about my efforts to do a reference implementation of an integration of Symphony 1.46 with OpenFin. It’s been an interesting exercise so far. I put all of this into a public Github repo and would be interested in contributing it to the foundation. I found some interesting gaps and things that we can talk about documenting better, or what functionality might be missing.

What I did was use the pattern we talked about in the WG. I inject a version of the sym_api Javascript into the frontend via preload scripts. The web app picks that up and uses some of those methods. Then I use some of my workflows in OpenFin to fulfill some of that functionality. The only one I’ve successfully done anything with is notifications. And there I’ve found several gaps. The first is that the notifications API has many more dependencies between webapp and container than are currently documented. We need to document those better. With the RegisterLogger function, there was another gap. Basically, I think that the webapp should have as few hard dependencies on the container and its methods as possible. When doing this I got errors and silent failures. I found one significant known issue I’m trying to figure out. When I pop out a window, I get a valid window with HTML content, but the content is not there. I assume there’s a disconnect between how the webapp expects to communicate with the window and how that works in OpenFin.

Next steps, I’d like to contribute this to the Foundation, do some more documentation, implement more of the features more deeply, and continue working with the group and the LLC to better document the APIs and come up with a process for managing changes to the APIs so developers can get early access to new versions of the API. It would also be great to get a timeline from the LLC on when the electron container will go into production.

Aaron Williamson: Any update on timefame, JC?

Jonathan Christensen: We’re targeting 1.48 (next next) as a beta. We don’t have a timeframe for production or full release yet.

Nick Kolba: [Demos web app running in OpenFin and known issues.]

Lynn Neir: Maybe we could work offline to debug that. On the logger API issue, we can remove that dependency because it’s really a private API.

Kevin Baressi: On the web-based version of Symphony, I guess the implication is that there’s a single codebase, but the desktop APIs just aren’t triggered if it’s running on the web?

Lynn Neir: That’s right, it looks to see if those methods are there, and if they are, uses them.

Nick Kolba: One other question for Lynn or JC. We got feedback from some customers that they were expecting a container in an end-of-September timeframe. Is that your target?

Jonathan Christensen: I think it initially was. Some priorities have changed, so I’ll take as an action to look into that.

Colin Eberhardt: I checked out the code and ran it and it worked fine for me.

Nick Kolba: Awesome, that’s great. Oh, and I also tried Container.JS with Symphony and ran into a lot of the same issues.

Colin Eberhardt: Yeah, we’ll give it a go as well. I didn’t realize until just recently that we had access to the new API methods in our environment.

Aaron Williamson: Pre-release web app?

Jonathan Christensen: We have a customer pre-release program, UAT. We also have a more aggressive internal program and I was thinking it might be possible to do something in parallel with the Foundation’s environment and more generally-available hosted pod. It’ll introduce stability issues.

Aaron Williamson: Official position on supporting third-party containers?

Lawrence Miller: Beyond the conversation we just had around the API and release schedule, what are you looking for?

Nick Kolba: Just a statement that there’s a commitment to the API and keeping it maintained and stable and not introducing non-documented APIs that are required but not supported or accessible. And making it possible for developers to access new versions of the API before they’re released so we can test against it.

Lawrence Miller: If it’s a question of testing within ODP, that’s a discussion we need to have with the Foundation. I don’t think it’s a problem, just a separate discussion.

Peter Monks: The API WG has had a similar conversation re: REST APIs, and they’d like similar pre-release access. Maybe we can combine those conversations.

Aaron Williamson: Lawrence, there’s another question here asking Symphony to confirm that it intends to open source the web app and to provide a rough timeline. I believe you confirmed that at the members meeting, but don’t recall if you provided a timeline.

Lawrence Miller: I’d refer to my comments at the members meeting. As for a timeline, we’ll be evaluating the front-end code later this year and will provide more information as it becomes available.

Action items

•  Jonathan Christensen: Let working group members know whether Symphony LLC is still targeting the end of September for the release of the production Electron container.

Agenda

Attendees