Next Cloud 18, it will become much easier to build your own components and automate your task. How you can do this will be presented by Bliss in his talk, Building Next Cloud Flow. Have fun.

Thank you very much, and good morning to day two. About Building Next Cloud Flow, first maybe one sentence about Next Cloud, in case you don't know it. It's an open source platform. While that was initially built around thinking and sharing

files, and now it's sort of like an open source 365 alternative. And Next Cloud Flow, the ambition

is to have a flexible and user-defined event-based task automation. So what we try to do with this is have maybe something like, this is the stream. This is the stream? OK. We got this one on the stream, and can you flip it?

Yeah, of course. Sorry. Where is it? Here, here, here, here. OK.

OK. That's better, I guess. OK. So maybe you know stuff like, if this and that, where you have components that trigger some event, something happens, and you have some criteria, and then something else should happen. This is what we try to do here. And previous to Next Cloud 18, which

will be released in January, we already had something in place, but it was far more limited. It was limited to files, and only administrators could set those flows up. And we were having basically four use cases,

or four actions that we could do with that. It was blocking files. It was tagging files, converting them, and running a script. So yeah, also the UI was a little bit scattered. The mechanism that was providing interface for different apps

that they could implement it, and if you would have then such an app enabled in Next Cloud, you would have one, two, three, four different, or more entries in the settings. So this was not so very nice. So these limitations we wanted to break.

And the goals, or the objectives then were to have a nice user interface that's kind of not too complicated, where you can rather quickly click those flows together that you want to have. And not only for administrators, but also your end user should be

able to configure such flows. Maybe not everything, not just running arbitrary scripts, but on the other hand, maybe they should be able to write something in their conversations in Next Cloud Talk. Still, the rules that were already set up,

they should continue to work, and should be extendable. Because we want to provide more, and to give you the opportunity to have different triggers that can be acted upon.

And so this is the state here from one, two weeks ago, I think, how the interface looks like. You are locked in as a regular user, and the flow settings. And here, this is the event. This should cause this flow to work.

And here we have now check, so the constraint. And what will happen eventually is to write to a conversation in Next Cloud Flow. So in this demo, file creation, for instance, was configured. And then it should be written into.

And this will be now shown here. So the user now creates this event themselves. But this is, of course, limited to owners of such files. But if it's also shared, or publicly shared, this would also create this event, obviously.

So here, this editing happens. And in a few seconds, we will go to Next Cloud Talk. That's this chat, or conversation solution.

And here, the bot was writing the lines into it. So this is how one flow basically works. And this is already in. And further, I want to go down into details

how this works internally. So that's why we have the demo up front. And we go then deeper and deeper. And we'll also see how it's possible to create own components for Next Cloud Flow. So everything's based, of course, on Next Cloud Server.

And we have this workflow engine, how it's called, that provides or knots together all these different parts. And these are separated into these three things. The entities represent, basically, the action, the trigger, that's causing the flow to happen.

The checker, they are therefore to check the constraints, the criteria that you configured, and the operations, eventually, the action. So these are the terms that we use in the code. Basically, it's the action and events that we say.

Well, on top of it, of course, there's a web interface. And kudos to my colleague, Julius, who did everything that's actually user-visible on the front end. That's the magic, real magic. OK.

So flow cycle, kind of to have it also visualized in this way. So we have an event that happens that's represented by this entity. Yeah. And this is fired. And the workflow engine, that becomes aware of it. There was an event listener activated.

And then it acts. It instantiates these different components. And yeah, the operation candidates are those that are configured for that event that was fired. And so yeah, it happens.

The entity sets a context, so gives more information to this service that's called RuleMatcher. And then the next step. The event handlers were called. And they also get access to this RuleMatcher. From there, they request the rules,

so the rules that are the whole sets that are configured in the UI. And the RuleMatcher, when it was requested, it does the execution checks. So it could be, which is the correct tag set.

Is the request time correct? Or does the user have actually access to that object that fired the event? So this happens. And it filters the possible operations. And it returns them. And whatever's left in there, that can be actually

executed, like written into the conversation room. So the engine is the cure part. It's a central point that takes the registrations of the components. We have a couple that are built in.

But everything can here be extended by their own apps. Like the example of writing to this talk conversation, this is also in the talk app. So that's not built in itself. Yes. The listeners are set up automatically,

so that it always listens to the post events. So if something has already happened, then this listener will become active. There are some special cases where an operation needs

to become active earlier. This is a case for attacking or for the file's block access, because you should block a file before it's being accessed or downloaded. And we come to this a little bit later again, because it offers a flexibility to go beyond this.

Yeah, the engine provides information and takes care of the heavy load, the complicated stuff, or also the boring stuff, the housekeeping. So yeah, let's start then here on the right side, what

you have seen before in the screenshots. Yeah, the action that is being then done, that's defined in an interface. It's the I operation. And in this implementation of it,

we provide a part that is being visible for the users. The scope means here at the moment, is it a rule that's defined by the admins, or is it a user-based rule? And the validation takes place here in the event handler.

So yeah, on event when it should do its stuff, then this is being called. And yeah, there are two refinements of it. The I specific operation, this one is limited to a very specific type of event.

And yeah, this is, for instance, the PDF converters that can only act on files, so that's limited to files. And the I complex operation, this is a little bit more advanced, and does more stuff of its own,

like its own listening logic, which said before, is necessary for the files block access, like a firewall thing that prevents you to have the files outside of Next Cloud. And yeah, this does the stuff by its own,

because it needs to interact already deeper in Next Cloud. So here we have an example, a code example of the PDF converter. And this is the first part of the implementation of this interface. Get display name, well, it's clear.

There's a description, and it also has an icon that's being presented. It's quite straightforward. Then the next part is the available scope. And an int is being passed in here. And there are constants, admin or user one. And it simply returns where it is available for.

In this case, true, so it can be set up by both administrators or users. So regular users, to have context samples, the external script runner, it's only

available for administrators and posting to conversations only available for regular users. And here's an invalidator. So it gets some parameters.

You see here the possible modes. That's what comes into the back end from the user configuration. And it just checks whether that's properly configured. And if not, an exception is being thrown. And if everything's fine, then yeah, it just passes.

We have the on event. That's the listener itself. And this is the real task, the real logic that the operation is actually being run. The PDF converter in this part, first it gets the notes somewhere that's a bit truly boring.

So the note, that's a representation of a file. And then it just makes some check what it should be done. And in the end, it adds a background job that will be then later called by or executed by cron. Because PDF conversion can take a little bit.

So you don't want to have it in a regular user action, like an upload or editing a file in the web. So that's why this is being delegated to run a little bit later as a background job out of the user request.

It's a nice specific operation. So this is only available for all the files. And a different example is the access control. That's things that can block the files from being accessed outside of Next Cloud.

And here it gets a trigger hint, which is then shown instead of the event chooser. It's when the file is accessed. And on the event, this can just be a no operation. And in this case, it's a no operation because it does things in a different and a deeper

layer of Next Cloud. So that's why first it's not being called here anyway by the workflow engine. And that's why we don't need an implementation here. But the magic then, or the logic happens in somewhere else. That's then very custom to the app. Yes.

And of course, it needs to be, oh yeah, that's a registration here. It's a connect hook on the file system. This is where it happens and where a storage wrapper is being registered.

So that's what the file access is doing. So yeah, it goes a different way. And this is one of the flexibility types and option and mechanics that Flow Engine is being offering to you. But all operations have to be registered so that we become aware what is actually there

and that it can be also shown and displayed in the user interface. And yeah, this snippet is what it's doing this. It's a listener against this event. That's a constant as well. And yeah, when it itself fires this event

because it needs to be presented on the web interface, then it just gets the class. And in the last part, the JavaScript part is also being loaded so it can show its option

later in the user interface. So yeah, this is the front end part. Also, this is very straightforward because there are different defaults that you can use and don't need to do much more. So that's going to be a little bit

comfortable for the developer. But again, here it can be also overwritten by some own necessities, if you have them. They also do their validation. They can have different parts, and everything

is a view component here. We have also here snippets for this. At the first part, it's an automatic tagging operation. It says I have an icon of my own and have a color.

That's a green one here. So this is what is being shown in the selector. And further, it has the operations. There are none because it's just a picker. It could be, I think, yeah, let's skip it.

We have the options here. That's an own component of the tag. And there it kind of loads available tags that are there in the system and offers you the chooser to pick them.

So this is what it looks like afterwards. Yes. And when should it be done? Parts of the action, the trigger that should,

or that can be selected. So the iEntity, the file, again, is the most common example. In this implementation, you also need to provide some user-facing information, display name, et cetera. You can also give the events that you're compatible with

and provide some context. The file entity, we have an example here. It's a name, and it's an icon. And here are descriptive events. And they just give one, again, one label that is being presented.

And the actual event that is being listened to. So all these file objects, they throw different events. When it was created, written, et cetera. And we divide them by a namespace and with the actual name.

And similar, it is for the mapping event. And so you see, we have here just generic entity event. And this is an implementation of that one. It's an event name and a display name, just what we gave there to this class,

this generic entity event, which is also convenience implementation that's available in the public API. So in Next Cloud, we have in our namespace, this part,

there are three routes. OC, that's all the internal values. OCA, that's all for applications. And OCP, that's the part that's available in the PHP API that can be consumed by all the apps.

The rule matcher itself is being also prepared by this entity because it will provide the context. Here we get first the final dependent on the type of event that was being called

because there are some differences. So we get the notes of the file representation. We add it to the rule matcher and then also the operation can take advantage of it. And for those, that's also an old function that we need to take with us.

We set the file information. In most cases, so at least if it's not a bot file, you don't need this line, but just the upper one. And if a file is not found, then it obviously disappeared. So we just silently pass it because it's usually

not a narrow case that needs to be handled. Like, it could have been deleted in between or so or made unavailable, so it doesn't make sense to cause more work or awareness to the administrators.

There's a legitimization check. And it will figure out whether the user that's passed by UID here, whether it's allowed to have access to this entity. In the case of the file, first we check if it's an owner

and if not, whether it's a shared recipient. In that case, we say, yeah, it's fine. Yes. And it can also provide additional information. So that one was especially needed for the talk operation

because it would be very cumbersome for every end operation to figure out what text should I write here and what are the specifics. So this logic we also placed into the entity

so it can get the display name or it can get some display text. So this is implemented for file just a little bit longer. So I took out the getURL function and it will provide the internal file URL.

That's basically it. And then the operation that is working against this can take advantage of this information. And the last component, the checkers, those that set up the constraints,

they are defined via the ICheck interface. And they should offer the option to test against certain characteristics of the entity.

And so first method that is to be implemented, which identities are supported. File is one case, but you don't need to add anything. You can just have a generic checker.

For instance, everything that goes against the request because it's available via Next Cloud right away. And it can be against any event. You can check anything about the web request that is being done. And also here, for which scope is this actually

available, admins or users or both, as we had them before. Eventually there's the validator that gets two parameters. One is operator, as you see. And the other one is the valid that's being passed. And here we have one example of group one, the lower one

whether it's in a certain group. This is being checked here. And the first one is just very basic. That's a validation.

And then an executor itself, this being the logic. So let me make it a bit more clear. So the validation, that only checks whether the configuration itself that the user enters in the interface, whether this matches, or this is fine with what we know.

And this one is actually then the test that is being run when the event happens. So first, before we had checked whether the group is already existing, so whether we don't have an outdated value here. And when a flow is being evaluated, we will check whether the user questions actually

in the group. And this part is also exposed in the web interface. So also this one needs to be registered there. And also here again, it works as a Vue.js component.

And also here we see how it's being registered. This one is a file size check. So that's already code that we have in Next Cloud. And it has its own operators. So that's not an is, or is not, or match, or match not, which works against strings, for instance.

But this one checks against the file size. And it has a name that is visible and one that we use in the backend code to check against. There's the placeholder, so a hint, what you could offer. And the validator itself for the front end,

so that before you try to save it, you already know in advance whether it's going to work or not. Then it looks like this. The file system tag that has a custom component,

it works as is and is not operators. Otherwise, it looks very similar. But the difference here, it doesn't have an only component. But the file system tag does. And it itself just implements in this multi-select dropdown

and takes care of loading the values itself. So that's what's more special than the simple file size thing. Yes, so actually that's already from my part. I was quite faster than I thought I would be.

But if you have any questions about this, then I'm very happy to answer them. So everyone who wants to ask a question, raise your hands.

I will come to you. Thanks for the great talk. Just a small question for my understanding. The workflow will be in the way that the person can click it together, or does one have to program it like you just showed the single events?

So for the end user, it should be clickable, like I was showing in the video here. So this is already how it's the presentation

for the end user. Now it's for a regular one. For admins, it looks similar. So just your choices are then different depending on what's in the back. But it's done in a way that you can extend by yourself as a developer. So we already have lots of interest from others who want to take advantage of it.

And what I'm working on currently, but not done yet, is also one thing that could set up endpoints so that you can have requests or web hooks from outside coming in and work on that. So the user part, it should be easy to click together.

And for the developer part, it should be also comfortable to get your own components, one of those done. Any other questions?

Yes. Probably a very simple question. Can directories be observed? You can observe directories ideally by tagging them. So you create a system tag and assign it to the directory.

And then whatever happens inside, it can be watched. OK, because the background is when I hear workflow solutions, I think of things from print and publishing. And there a lot is done with observing directories and converting from one directory to the other. That would be something that would be expected from when

they hear workflow solution. Yeah, in the back end, it's like this. Or in general, it's like this, that if a file is somewhere in a directory structure changes, that also changes the modification times of the directories. So it also then issues the file has changed event

because directories are also files, right? Everything is a file. And so it's easy to select them by having a tag. But then you have the file changed event that will be also then executed for directories, of course. Thank you. You're welcome.

Can you maybe name some scenarios that you have in mind? And can you list some actions that can be taken place? Can mail be sent? Just to get an idea of what actions can be chosen.

So right now, we didn't have much time for possibilities to extend it over different entities or actions. But as I said, it's being worked on. And we have already said that part that kind of rides into a talk conversation.

And one idea that we also were having, but it's not done yet, is that if you mentioned someone in a conversation, it would check against the calendar if the person is actually present or maybe on vacation or in a meeting, and then would just

give you some informative line in the conversation. This user is currently not available. So that could be one thing about collaboration. Yeah. With a web request staff, it could be that you configure on GitHub or any other service

a webhook that triggers if something happened, wherever that next stop will be notified. Yeah, and then it can, right now it makes only sense also to write into a conversation. But you could also have a log file, for instance,

that is being then written into it, if you imagine this. Or you create a file or something like this. So that's not implemented, but this can all be done. So the idea behind it was to have it so flexible that you could basically do anything with this.

What you can see in other solutions, there it's more common that you have very fine-grained things that you can pick, like an issue was created in GitHub and then write an email here to us.

We don't do it so fine-grained because we just decided we had to more rough. So in this case, it would be also an external request and then just need to configure this somehow to do something.

But basically anything would be possible with this approach. And if you want, you can talk to Joss later. We have also a boat here at this open infrastructure orbit. And he's very good in kind of telling you

what really is possible. And he's also having a talk later. Hi, thanks a lot. I just wondered, once you've clicked together one of your workflows, how does it look like? How is it stored? Can the user actually take it with him? So if we set up another Next Cloud,

do I have to click them all together again, my precious workflows? Because these things can become quite mission critical. So I would expect some kind of script. I can read and copy and maybe even code. So I don't have to click it if I know what I'm doing. Yeah. That's an interesting idea.

It's saved all in the database that Next Cloud operates against. And I think altogether there are three tables where the rules are defined, where the constraints are defined, and where the scopes are also defined.

But this configuration interface, that all works with OPI calls. So you could indeed create a different client that would read out or write a workflow that's possible. And that also would make it possible for you

kind of to take out your flows. So yeah. So there's no nice way right now to do it. But there's a programmatically doable way to do it. OK. Then if there are not other questions,

thank you, Bliss, for the talk. So give him a big applause again. Thank you very much.