 Hello, everyone. I'm really happy to be with you today. My name is Riko Xdeen and today we're going to talk about building FDC3 enabled web applications. About a year ago, around about this time, I was up on stage off Broadway in New York at OSSF 2019. It was very exciting. This year things are a bit different. I'm doing this talk virtually, but in some ways I am even more excited about the talk this year because what I want to do today is make FDC3 really practical for people in terms of a set of steps that you can use to build real FDC3 workflows. What are we going to talk about today? First, a short introduction to myself. Then we're going to just briefly talk about why FDC3. Why should you be interested in FDC3 while we're using it? Then just a quick recap about what FDC3 is for people who are not that familiar with it. Then I'm going to show you in five steps how you can build an FDC3 workflow. Then I'll say something about FDC3 in practice out in the real world and how people are using it today. Lastly, there will be some time for questions and I'll share my contact details with you in case you want to get in touch. A little bit about me. I started out as a software developer in Cape Town almost 18 years ago and I've been working in the financial industry in London for more than 15 years. I started out doing everything from Delphian ASP through to WPF and Flash. Nowadays, I do HTML5 and React, but I've also done DevOps and backend services, a whole lot of different things. At Adaptive Financial Consulting, I'm the head of desktop strategy. What that means is that I've worked in several industry-leading desktop platforms over the years. I advise clients on what desktop technologies to use, how to build collaborative workflows and really how to put in place digital transformation in their organizations when it comes to their financial desktops. At Finos, it's my great privilege to be the co-chair of the FTC3 project and I am an active Finos contributor. You'll see pull requests from me every now and then. But enough about me. Why FTC3? Why are we here today talking about it? Well, what's interesting is that for a long time, we've been building front-end systems this way. You have a bunch of microservices and then you have a big monolithic application that aggregates all of those services together and displays a single front-end to the user. That might be a single-page web application. It might be a rich WPF application on the desktop. This approach has some advantages. There's a single code base. It's often easier to deploy that way, but it also becomes unwieldy over time and it's sometimes difficult for lots of people to work on this single application together. What we've seen over the last two years or so, maybe even a bit longer than that in the financial industry is that people have started doing this type of thing where you break things up into smaller pieces and you have individual micro front-ends running on the desktop. You kind of componentize your desktop into smaller pieces, much like you do with microservices on the back-end. The interesting thing to me about this approach is even if you think about the microservices on the back-end is that just putting the components in place, whether it's on the desktop or on the back-end, is not necessarily enough by itself. You need a way to orchestrate these components together. You need a way to discover them, to make it easier to deploy them. You need to establish patterns for them to communicate and collaborate with one another. On the back-end, Kubernetes is an example of an orchestrator that people often use nowadays to manage their microservices. Really, the same thing is true of the front-end. You need an orchestrator to help you with the micro front-ends that you want to deploy to desktops. There are a lot of vendors that operate in the space that offer products that make it easier to deploy micro front-ends. For example, in web containers running on the desktop, they also help with things like window management, ease of deployment, registering applications, etc. This is really the space that FDT3 is targeted at. It is an attempt to standardise the patterns that we use on desktops for orchestrating micro front-ends. It's particularly important in the financial industry because people have multiple monitors. They're using applications from third parties, multiple departments internally. People want to do windowing and workspaces and all of these types of things. In FDT3, there's a concept of a desktop agent, which is really a standardised way, a standard context for managing front-end widgets or components. The true power of componentisation comes when components don't work in isolation, but when you can connect them together, which is one of the most important parts of FDT3, is that it offers a standard way for interoperability between components on the desktop. While the analogy isn't perfect, I sometimes think of it as the equivalent of rest for microservices, which is a way to pull microservices together. FDT3 provides a standard way to do that when you're orchestrating on the desktop. Why do we want to componentise components this way and compose them together this way? Well, it has several benefits for organisations and really they're analogous with some of the benefits you get from microservices. One of them is that you can reduce costs this way. You can work on particular desktop components independently, which means that different teams can build different components in parallel. You can release them independently. They can be decoupled, which means that everything doesn't have to be necessarily on the same timeline and you remove this need for big bang releases of a big monolithic UI. You can use different technologies for different components and they can still all work together, so we can just be much more efficient about how we build front-end components. Similarly, we can unlock new opportunities. We can pull together applications that were previously not able to pull together because they are built in different departments. They're completely isolated from one another. There's no way for them to interact. With these type of patterns, we can create new opportunities, new user workflows by connecting previously isolated pieces. It also offers a path to migration for those big legacy applications, which are so hard to migrate because you can start to break things apart into smaller components, still keep the workflows in place and migrate them bit by bit or just the bits that make sense. We can even have new opportunities in the industry across organisations for various vendor products, third-party systems, STPs to all work together. Finally, we can start to leverage network effects on our desktops. My talk at OSSF last year was about leveraging the network effect, so if you're interested in this, please go look up that talk on YouTube. You can find it there. Really, all of that this is about is putting more nodes into place, connecting, making more connections between those nodes, and you start to reach a critical mass where you start seeing exponential value from putting more pieces in place in your network. This effect is behind a lot of transformative movements in technology. We really want to create an environment where we can start leveraging that effect when we work with smaller components. What is FTC 3? It stands for the financial desktop connectivity and collaboration consortium. It was started by OpenFin in 2017 and then contributed to the Fintech Open Source Foundation, and FTC 3 aims to establish open standards for the financial desktop. The 1.0 specifications were released last year and adopted by quite a few organisations. In April of this year, we released 1.1 specifications and the FTC 3 standards working group is actively working on the 1.2 version at the moment. We have a web portal at fdc3.phenos.org where we've tried really hard to make it easy for people to understand FTC 3, understand the patterns. There's usage examples, API references and other documentation. Please go and have a look, get involved in the community. It's all open source on GitHub so everybody can do pull requests, contribute, raise issues, etc. Very recently, we've been able to publish an NPM package for FTC 3, which is something we've wanted to do for a long time. For those FTC 3 applications using web technologies, this offers a great entry point and standardisation of the types and operations you can use in an FTC 3 desktop context. We're quite excited to be able to offer that to people. Please go and check it out. FTC 3 is made up out of four specifications really in the standard. The first one is the upper directory specification, which just offers a shared way to register and discover applications. The second specification is the intense specification. If you've done Android development in the past, you might have come across intense, the concept of intense, and all they really are are well-known verbs that you can invoke or reference. So for example, an application might raise the start chat intent or the view chart intent. These intents are examples of standard public FTC 3 intents. So they're well-known applications can use them. Another application will then be launched to respond to that intent with the idea that the applications don't need to know about each other, they just need to know about the intent. What goes closely in hand with this is the data that you exchange as part of the intent being raised. So if it's a start chat intent, some information about the contact that you want to chat to, if it's a view chart intent, you might want to send the instrument information that you want to view the chart for. So FTC 3 provides a standard envelope for exchanging contextual data and it also includes some standardized contacts for things like instruments and contacts that people can use. And finally, there's a shared set of deliberately small and lightweight operations that applications can use to collaborate with FTC 3. And FTC 3 is agnostic of which desktop environment or which technology it's running in. A lot of people use web technology to write desktop applications at the moment. So that's where we see it use most common, but you can also use the APIs and the other specifications with, for example, .NET applications running on the desktop. So that's FTC 3. Let's try and make things practical now. So what I want to do today is share just five steps with you that you can follow for building FTC 3-enabled web applications. And the key point here is really that we're not building a single application, but we're building a workflow. When you're doing componentized desktops and interoperability on the desktop, you're really thinking about how multiple applications work together. So you're not designing the behavior and the look and feel of a single application anymore. You're designing the collective behavior and look and feel of multiple applications. And designing the workflow is an important step that people often miss out. You've got to think carefully about how everything is going to interact because that informs everything else. So we're going to start off by doing that. Then we're going to define the actions that the applications are going to use to collaborate. We're going to model the data for those actions. We're going to register the applications with the FTC 3 desktop agent. And finally, we're going to use the FTC 3 APIs to make it all come together. So the workflow I've chosen for today is an FTC 3 trading app with which you can trade FX currency pairs. So there's some streaming prices, you can click by yourself, and then it will say that there's a pending trade for a particular notional at that price. The buttons then become disabled while that trade is pending. This will then launch automatically, dynamically an execution app which will receive the information about the trade that needs to be done. And that trade can then be accepted or rejected, which will remove it from the status and add it to the trade blotter. And then it will return the status either accept or reject of the trade to the trading application which will update its status. So this is a relatively contrived example, but I wanted to simplify things down to something that is nice and simple for us to work with. In the real world, the same person might not do all of these actions and might not all be happening on the same desktop. But yeah, I think if we follow the steps that I mentioned for this workflow, it will help to illustrate how you can do some similar things with real workflows. So now we need to define the actions that the applications need to collaborate. How do we start with that? Well, the great thing is we now have a workflow, so we can use that to help inform the actions that need to take place. So the first thing is the trading app needs to raise an intent so that the execution app can come up and respond to that. So we're going to call that intent execute trade, we're going to raise an execute trade intent. And that's going to carry along the data of the trade that needs to be executed so that the other application can use it. And then when the user clicks Accept or reject, it needs to return the trade result to the original application. Now, at the moment in FTC 3.1.1, intents are sort of one way. They don't return data, but in FTC 3.1.2, we're currently working on intents that return data. Because this is a FTC 3.1.1 workflow, I'm going to use a different mechanism from FTC 3 to return the data. And this is called channels or broadcasting. So we can create what's called an app channel, which is a channel that both applications know about. And we can return the trade result via that channel. And this also serves to show off a bit more about the available FTC 3 APIs. So we know that the two actions we're going to need are to raise an intent and to broadcast on a channel. And for each of these actions, we basically need an identifier. So in the case of raising an intent, we've already said this is the execute trade intent that we're going to define. And along with that intent, we need to define the data that will come with it and how that payload looks. And we're going to call that a trade request. So for the raise intent action, the identifier and the data is really the only two things that both applications need to know about. They don't need to know about anything else or about each other. But these are the two pieces of shared and agreed data or identifiers that the collaboration is going to be based on. For the broadcast on the channel, we need to agree what to call the channel so that both applications can reference it. So we're going to call it the trade result channel. That's going to be its identifier. And we need to model a trade result that can be exchanged on that channel. So for the two actions, these are the four pieces of data that are the minimum that we need to couple and connect this workflow together. Right. So how do we model a trade request now that we know we need it? So in FTC 3, we've adopted JSON schema to help model data. And some of the existing FTC 3 data types are modeled with JSON schema. It's not the only way to do it. But I've come to kind of like JSON schema. I find it intuitive and logical once you understand how it works. And I'm going to try and show you today how you can use it to model the trade request. So to start off with, you need to say what version of the schema you're using, the identifier of the schema, and then just that we're modelling an object, which we're going to call trade request. So that's kind of the header of the schema. So this is the first nice thing is we can now reference existing FTC 3 schemas to help us. In this case, what I'm saying is I'm going to base my schema on the FTC 3 1.1 base context schema. So that has the minimum properties that an FTC 3 context type needs to have. And really all that is in that schema is a type property, which needs to be a string, which identifies the type of data we're exchanging. So when we are extending that schema into a trade request, we're going to be a bit more specific. And we're going to say, well, it's not any string anymore. We know what the type is in this case, it's an adaptive trade request. And here we're using a convention in FTC 3, which is to prefix the context types with the organisation who's defining the type. So that standardised FTC 3 schemas use FTC 3 dot and then the name of the type. So we're going to have an adaptive trade request type on our payload. And then what FTC 3 also has is sort of a bag of identifiers for this data, which applications can use to decide if the data is relevant to them. So in our case, we are just going to require that there's a trade request ID as a minimum. That's going to be the only identifier for this object that we're going to require. Applications can stick other things in that bag if they want to, but this is our only requirement. And then we need to represent the instrument that is being traded. And here is a great example of how we can compose more complex types from existing FTC 3 context types. So I'm using the FTC 3 1.1 instrument schema here, and I'm just saying we're going to have an instrument property which has an object which has the shape of an FTC 3 instrument schema. And then we're going to add some additional things like is it a buyer or a sell, what the notional is, what the price is. And if I want to, I can also use some other FTC 3 schemas to represent the counterparty or the contact for the trade. I'm not using that in this workflow, but I just wanted to show how you can use composition to build up complex types. So for this example, they're not going to be required as part of the data type. So I haven't included the counterparty or contact in the required list of properties, but they can still be used optionally. So there's our trade request schema. How would that look in practice? Well, there's an example of a trade request that adheres to the schema. So there's the type at the top, the identifiers, which includes the trade request ID, the instrument which uses the shape of an FTC 3 instrument schema, and then the side notional price and the counterparty just to show how that would look. And there's our trade request. For trade result, it's much the same thing. We're going to have a type which in this case is adaptive to our trade result. We're going to have some identifiers. Let's say in this case, we kind of want to know both the trade ID and the trade request ID for this trade result. And now I can reuse my trade request schema in this trade result schema by just referencing it. So I can say there's going to be a trade request, which is going to have an object that adheres to the trade request schema inside it. And I might want to add the status, which is accepted or rejected, and the timestamp for the trade to that. So that gives me my trade result schema. And now we're done modelling the data. And what I want to show you now is quite a cool little tool that we've used in a few projects that are FTC 3 related. And this tool is called QuickType, and it can be used to generate code from JSON schema for the types that you want to use in applications. So I'm just going to quickly show that to you. What I've got here is the same trade request schema that we've just modelled. And by just sticking it into QuickType, it will generate typescript types for me and a utility method to go from and to JSON payloads with those types. So that is quite cool, I think. You can also do things like say that you wanted to verify it and validate it according to the schema. If you wanted to, it will generate all of that code for you. And it really works for just about any language that you want to use. So for example, if you want to generate the code in Java, it will use Jackson and do all of the formatters for you to serialize and deserialize to and from JSON. Similarly, if you're using C-sharp, it will use jason.net to create the types with the right attributes for you. And QuickType is an open source project. It's on GitHub, and it is also an NPM package with a command line tool that you can install to use it in your projects. So that's QuickType. It's a nice tool when you're doing data modelling to then use those types in your code. And that's what we've done in this example as well. So what have we done so far? We've designed the workflow that we're going to use. We've defined the actions for that workflow, and we've modelled the data that those actions are going to use. Now we need to register our applications with the FTC3 desktop agent. Why do we need to do that? Well, if you think about it, what's really happening here is that one application is going to raise an intent, and then the other application is going to magically appear. What's happening in reality is there's an FTC3 compliant app directory which has a record of all of the applications. And when one application raises an intent, the desktop agent is going to use the app directory to find the right application to raise that will accept that intent. So the app directory is an open API res schema. So it's sitting somewhere in the cloud, and the applications are registered with it, and the desktop agent uses it to pull the workflows together. So if we've registered our trading app with it, it will then go and find the right app to meet the intent and launch it on demand. So to make it work, what we've got to do is we've just got to add a record with the REST API or with a UI to the app directory with the identifier for the app, the name for the app, the manifest, for example. It will have windowing information, et cetera, that is needed to launch the app and other properties like icons or descriptions that you might need or use for an application launcher. But those are the sort of the minimum things you need to define for the app. And then for the execution app, we need a little bit more than that. We need to tell the app directory and the desktop agent which intents this app responds to so that it knows to launch the app on demand. So in this case, we're going to add execute trade intent to the intense array for this application. And we're also going to say that the contexts that this app understands for the execute trade intent is the adaptive.trade request that we've defined. I can specify as many contexts as I want, but the key thing here is that the desktop agent can use this information to root to the right application. And now you also understand why the type property of context data in FTC3 is the only required bit because it's used for filtering and routing requests between applications. Right. So doing this, we've registered our applications with the app directory. And now the only thing that's left to do is to actually write the code and use the FTC3 APIs to put the workflow together. So that's easier than it might sound. There's just a few operations we need to use. To start off with, we probably, both applications need a reference to this channel that has been agreed ahead of time so that the trade result can be exchanged. So having got a reference to that channel, the trading app then wants to add a context listener for the adaptive.trade result type that we've defined so that it can receive it and so that it can then update the status about where the trade has been accepted or rejected. And it probably wants to do this before it raises the intent because if it does it after raising the intent, it might miss the trade result while it's still setting up the listener. So we're doing it ahead of time. Then we're going to build up the trade request according to the schema that we've defined. And then we just raise the intent, the execute trade intent and we pass it the trade request that the other application will need. All that the execution app needs to do is it needs to set up an intent listener for the execute trade intent and it will receive the trade request and then it displays it and the user accepts or rejects the trade so we build up the trade result. We embed the trade request in it according to our schema and then we are going to broadcast the trade result back to the trading app on the channel that we've defined at which point it will go to the context listener on the trading app. And that's all we need to do. We've now followed all of the steps to build our FTC3 workflow. So yeah, let's see it in action. I'm going to show you a demo of this trade workflow now that follows the steps that we've defined. Right. So what I've got here is a sandbox that we use adaptive to test and experiment with FTC3 applications. And this sandbox just runs in the browser. It opens other browser windows and it uses post message to communicate between windows. So this just goes to show that FTC3 isn't opinionated about what desktop framework it is running in. It just provides the standards and the connectivity to bring the workflows together. So from this desktop agent, from the sandbox, I can launch my trading app. I can launch my execution app. Right. And what you will see is I'm now going to try and do a trade and show off the workflow as we've designed it. So here I'm going to click sell and it's going to say that the trade is pending. But the problem is that the execution app hasn't come up to respond to that. And the reason for that is that I haven't written that code yet and we're now going to do that together. So what I've got here is the code for the trading app and the execution app. They're both relatively simple react applications that use react hooks to wire everything together. So they both define some state. And what you will see here is that both applications get the trade results channel that we've defined. And then the trading app sets up a context listener for the trade result. And if it receives a trade result, it will add it to the state. And this is the code for handling a trade. So when a trade button is clicked, we build up the trade request with the information from that trade action like the side and the notion on the price. And we set it as the pending trade. But now we need to raise the intent so that it can transfer to the other application. So I'm going to do that now. So I'm going to say await fdc3 dot raise intent. And the intent I want to raise is called execute trade. Oops. And I am going to pass our trade request to the intent. So I'm going to save this file. This is live watching the code, the web application. So hopefully, if the live watching works correctly, by adding this line, it will now, my workflow will now work correctly. So let's see if that worked. So I'm just going to close it down and open it again. Right. So let's see if that works. Oh, it worked. So just by raising the intent, the desktop agent has now brought forward the right application, is displaying the data and I can now accept or reject. This might not be a surprise to you, but when I accept or reject, it's going to add the trade to the blotter, but it doesn't report back to the original application. And again, that's because I haven't implemented that bit yet. So I'm going to do that now. So on this side is the execution app. We've taken the channel we've added to the application state. We've set up an intent listener and when the trade request comes in, we're adding it to the application state. So here I'm going to handle the trade execution when you click the accept or reject button. So we're building up our trade result. According to the schema, we're putting our trade request inside it along with the status, whether it's accept or reject. Here we're adding it to the blotter. So what I need to do now is I need to use the channel that I've got a reference to and just broadcast back the trade result, which will hopefully hit the context listener on the other side. So I'm going to do that now. I'm going to save it. Again, if the live watching is working correctly, the workflow should now work. So I'm going to close this guy down. Let's just reload this guy. Right. So let's see if our workflow works. So I'm going to buy the trade. I'm going to reject it. And now this application is updated with the status. So just with that, I've implemented my workflow using the FTC3 APIs. The desktop agent is smart enough to know if I do it again, that this application is already running. It doesn't have to launch it again. And it can just do the same thing over again. Right. So there's my FTC3 workflow implemented. And just to show you that FTC3 is underpinionated about what desktop environment it runs in, I'm now going to be brave and try and run this workflow in another desktop agent, OpenFIN in this case. And I'm going to use the same applications and register them with the FTC3 app directory of OpenFIN. And hopefully that will work. So let's bring up my console. So what I'm going to do now is I'm going to say I'm going to run everything up in OpenFIN. And so this is now the same sandbox that is running in OpenFIN. But in this case, it's just an application now. And it's delegating all desktop agent responsibilities to OpenFIN, which is acting as a desktop agent now. So I'm right along with running in the browser window. I'm running on an OpenFIN window on the desktop. And I should still be able to launch my app just like before. And it will come up. And if I click by a cell, it will still use raise intent. But in this case, OpenFIN will resolve that intent and should launch the right application for me. So if I do that, the execution app comes up. And I can now accept or reject the trade. And it worked just like I've showed you, but it's now doing it in a different desktop agent, because both are using the same FTC3 standards. And that's really the true power and beauty of FTC3. Right. So that's our trade workflow. So just to summarize, we've gone through five steps to build an FTC3 workflow. And I just want to list them again. And notice how each step follows into the next one. So there's kind of a logical order to them. We design the workflow, which then helps us to define the actions we want to use, which then determines how we model the data. Then we register the applications with the types that we've defined. And then we can use the FTC3 APIs for the workflow. So just to show that this is not all smoke and mirrors, I want to show just to tell you about a project that I've worked on where we used FTC3 in practice in the real world for a successful project that Adaptive has done. Very often, we can't talk about the projects we do for our clients. But in this particular case, the client at West Markets has agreed to do some publicity with us. And I can tell you about the Scout project. There's a case study on our website, which you can go and download and read more about it. And what we built, I was involved with this project and I was the tech lead for this project along with some people at Adaptive and at West Markets. We put in place a full desktop workflow incorporating the symphony, chat platform, open-fin-inf ensemble and RFQ desktop components, some of which were written in WPF and some which were written in web technologies with React running on the desktop. And for this, we used FTC3 intents. We used the FTC3 context data schemas and modeled some data. We used the FTC3 APIs. And it was a wonderful workflow where salespeople could chat to customers in symphony and at the click of a button, they could transfer into components running on the desktop where they can do pricing and then send those prices for an RFQ back to the customer they were talking out, all seamlessly, all done with FTC3 and desktop agents. Yeah, so that was a very successful project and it shows how people are leveraging FTC3 in the real world to solve problems on the desktop. And that's really what we do at Adaptive. We deliver bespoke software solutions for our clients. We've been doing it for more than eight years. We've delivered more than 75 solutions. I counted them and I think at least 18 of those were desktop integration projects using many of the same patterns and approaches that I've talked with you about today and so much more. So if you want to come and speak to us about a similar project at your organization, please do so. We'd be more than happy to talk to you and help you with that. In addition, we're willing to share our expertise with the community. We can come and do a presentation inside your organization about FTC3, about desktop strategy and we've also offered to do workshops and training for organizations about FTC3, whether that's for your developers or your stakeholders, please get in touch with us if you're interested in that. Yeah, so that's everything. I've put my contact details up there. If you'd like to send me a message to ask a question or to comment, please feel free to do so. It's been wonderful to be able to speak to you today and thank you very much for your time.