 Cool. So, hi guys. I'm Mehdi. I'm going to talk about the App Hub. I'm going to talk about the new published workflows we've been working on, which will hopefully allow you to publish updates through your CI and CD pipelines. I'm going to talk about the App Hub Guidance, which we've updated very recently, and that, well, you should follow when you submit to the App Hub, and I'll walk you through that. And I'm going to talk about new updates, so things that we've been working on, new features, a new user experience, and how that's going to affect you. So, published workflows. I'm going to talk about the existing workflow of uploading apps directly through the web interface, and I'm going to be talking about the upcoming feature, but we're very happy to introduce very soon hopefully, which is using the D2 command line utility to publish your apps directly from either your CI, CD pipeline, or maybe even manually from your machine, which is a workflow very similar to what you may have with the experience through NPM and maybe some other package managers. So, the current workflow that some of you may have experienced is using the web interface of the App Hub, where you see the screen, where you've got four sections, your general, version, developer, and image sections, and then provide the information manually. Now, of course, the obvious information will be similar for all of your apps, like your developer information should be the same for most of your apps if you're part of the same organization, maybe even some of your logos and screenshots are very similar, and then your version information, as in the minimum, and maximum DHIs versions might be similar across applications. So, I wanted to standardize this workflow to make it easier for you guys, and we've introduced API keys as well as the D2 publish tool, which I'm going to walk through now. So, before we can discuss these tools, I'd like to talk about the new API key screen of the App Hub. So, if you go on the sidebar, you should see an API key section, which will invite you to generate your own API key that can then use to talk to the App Hub. And this API key will be, well, first of all, it should be treated as a password. So, each user, so each App Hub user, so that will be your own account on the App Hub, gets its own API key, and that key lets you do pretty much anything that you can really do through the web interface. And because of the power that comes with it, it should really treat these keys as passwords, so please don't commit them to any public repos. Store them as a secret in your CI pipeline. Most pipelines allow you to do that, and, of course, if you need any help setting that up, feel free to contact me and I'll try to help you out with that. Now, currently, you get one API key per user, and we're hoping to make that more granular in the future. Maybe multiple API keys per user organization. Then you can really separate your different roles and responsibilities. So, if you have any feedback about how you think that should look like, please feel free to get in contact with me. So, this API key is very important for an upcoming feature which is publishing through the D2 utility, and you will just be providing that API key as an environmental variable to the script, and that will allow the script to just talk to the app directly without having to use the web interface, and then, of course, it will make it much easier to integrate with a pipeline. And this new published script uses the configuration in your D2 config.js, which should already be present in an app platform app. If you're using a, if you're not part of the app platform, sorry, if your application is outside of the app platform, you'll probably have it manifest, and we recommend just moving to the new D2 config and then using that. And through the D2 config, you can specify your app version, your minimum DHIs version, maximum DHIs version, and have information that you normally provide in the web interface. And this script is very similar to existing JavaScript tooling like NPM, so some of you may have used NPM published before. Our tool is pretty much exactly the same. It just takes your app, creates a bundle, and then uploads it to the app using the API key. We're hoping to release this very soon. We've got a PR open that we've been working on very hard lately, and we're just hoping to make some finishing changes and push it through. And yeah, so this new script will allow you to integrate your publishing workflow with your CR and CD, so doing it manually. And what we recommend is having one branch for the stable version of your app that you think should be published via pub, maybe another branch for your development work, and then having a workflow take that stable branch and then just publishing every commit using the published script. It's very similar to what we've been doing for our repos where we tag each release, have a version and publish to NPM. So if you guys need any help, we've really got that experience that can help you guys with. Now, the submission process. So we're submitting an app to the app hub team. We'll first be pending. That means that only you can see that app, and then the app hub team will be reviewing that app within the week or two. Normally it only takes us a week or two to actually get to apps and review them and provide feedback. And all we do is check whether the app is suitable and that you follow all guidelines. Once an app is approved through each version, it does not require a review. So don't worry if you need to get a bug fix out quickly if that's not a problem. And a game rejected isn't that big of a deal. It just means we have some feedback that will be incorporated and then we'll review as soon as that's dealt with. So to help us make reviews as quick as possible, please document your apps very clearly with killer names and descriptions. You can actually understand the purpose of the app and what we should be testing. If you can provide example use cases or example data, it's very useful as well. And even more preferable is linking to your source code. And that would be your unminified uncompressed source code. So you can really look at how it works, how it communicates with instances, and help us provide better feedback. And of course, up-to-date contact details allows to email you much quicker and get that feedback that you need to get your app approved much faster. Now I'm going to talk about the submission guidelines which has two sections. The first one is for required information and the second one is a wider range of guidelines but I'll walk you through that in detail. And of course the guidelines are available online. The latest version is available at this link on the developer portal and since the documentation is open source if anything is unclear please just you know, follow the reaper, make your changes and submit pro requests. We'll be very happy to review your changes and try to make the text more clear. Now required information. So I'm going to be walking you through any information that really absolutely must be included for us to prove an app. First of all is the app name that should be very clear and descriptive. Try to capture what the app actually does in just a few words. Have the users browsing the app hub on exactly what they're looking at. And try to avoid things that are very similar to other apps available both on the app hub and provided by us. That way it just makes it easier for users to it makes them less likely to be confused with other apps and it's just better overall. Now the your app icon. By making a unique app icon, you'll make your app really stand out on the app hub. And it allows users to once they've installed the app differentiate from the others in the application menu. So it's actually quite important to be unique. It doesn't have to be a work of art. We just want something that is very clear and unique. And your description is also important for users that actually want to explore what your app does on the app hub. So once they click through I'll see your description. This is pretty much the first thing they see. And it should just answer two questions really. What does this app allow the user to do and who is it useful for? We've also got screenshots and source code as part of our required information guidelines. So screenshots are just two to three images of most important screens of your app. We cannot put as many as you think are useful. We don't really have a limit. But there's no need to show every screen. Just focus on the main ones and try to show any example data if you can. Place all the data, since empty screens are very useful. Your source code. So if you can provide a link to your source code on maybe GitHub or GitHub or any other public platform that will not only allow us to review your app much quicker but allows technical prospective users to really explore what your app does and if it's correct for their instance. Now another guideline we have is that it should be generic. So they should be able to run any DHIs to instance within their specified range. So there shouldn't be any weird custom implementation dependencies or other things like that. Your dependency should all be open source as well. So of course when you think your code maybe on GitHub or GitHub should be able to see all your dependencies. This is clearly there should all be open source with correct licenses. So that is that if you can relicate to third-party services, they don't have to be open source. But please mark it very clearly in your app's description that you do talk to third-party services. And of course we have a design system where we lay out the principles and expect user experience of our apps and we expect your apps to follow them too. Now to make that much easier for you guys we've created a DHIs to UI package that has already made to react components to implement the design system completely and all of our apps use it. So I recommend that you guys use it too and I'll just make everything much easier. Now if you're using the app platform you might have noticed that we insert the header bar component automatically. But if you don't use our app platform then please include the header bar component that way all apps will have a consistent menu and information at the top. Of course you need some documentation as well so if you could provide a user manual or any other kind of information explaining to users what your app does, how to use it, how to get up to speed that makes reviewing normally much quicker and makes it more like for others to use and contribute back to your app. Now we had a workshop on security and performance. I'm going to go through this kind of quickly because I recommend you look at the workshop for more detail but essentially our security guidelines are the same as what we've discussed before or apps should be following up-to-date security best practices. You should not be hard coding any passwords or usernames and please avoid a data store, try to use a user data store which limits who can access the data and of course please use cookie authentication instead of basic authentication that way we can leverage the existing login and workflow that we've created and regarding cross-site scripting if user reacts you don't really need to worry but without frameworks make sure you've enabled all protections. Now on our app hub guidance webpage we've listed out the security requirements in much more detail along with any tips that we have. Now performance, same as what was discussed in my workshop yesterday, please use pagination. Some instances we have a large number of users and organization units unfortunately but through pagination we can work through that and make sure our apps work everywhere and please don't assume it fast on stable network connection and that's why we recommend you specify the fields you need from the API and that will significantly reduce the bandwidth required by your app as well as making it much more snappy. Now updates so we've got a new redesign of the app hub coming through and through that a new user experience that should make it easier for both users and app developers to submit and examine apps so we're very happy to be providing you that in the next few weeks hopefully, maybe even by next week and with that we'll also be providing a new app management app in the next DHIs to release because we're really focusing on investing in the app hub making it a better platform for app updates both from our side and from the side of external app developers so we're really much looking forward to those updates. So that's it from me.