Now, we present to you Gautier Bastien, he is a team leader at Himio, and Olivier Delar,

he is a developer at Himio, too, and we are together in the same team. We talk about using Plone to build a business application. I know it's hard to be complex, really hard, hard complexity on the workflow and the access right with Plone.

We will talk about two applications of the same solution, Yadelib, which is the main core and the main business app,

and the elevation.be, which is more like a portal to export data to the people. Yadelib is quite famous in Belgium, we have a lot of customers,

and so this much customized quite a challenge, I think Gautier will speak about it later, but we have a team of five people, we are managing a lot of applications, and this application is quite complex.

It's quite complex, but all the nasty stuff I save it for Gautier because he knows better. Who are our customers? Basically, there are municipalities, there are police zones, there are firefighters,

there are public social help and so on, everything that's public, but at the low level of hierarchy, like a big map close to people. This is a simple version of our workflow, you see there is a lot of steps, a lot of process,

because Yadelib is an application for the municipality administration to build a decision point that goes through the administration to the council, and then is discussed in the council,

and after the council is shared with the people and so on. I won't talk a lot about the workflow because the nasty stuff is for Gautier. Okay, thank you. I'm still a little bit at the party.

So, what we do here with Plone is something that is not current, it's not due often, we build an application with it, and to do so, we are using some specific package for the team,

for example, to manage dashboards, we need also to manage generation of desktop documents,

like PDF, docx, excel files and so on, and we need also to manage contacts, so people and organizations in the application, and to us, the workflow is a very basic

and important piece of the application. With all these tools, some years ago, we built a new application in four or three weeks.

In four weeks, we had an application with dashboards, document generation and so on, so it's very quick to build a new application. So, we use the stack collective contact and collective EAFS-TIT,

all this is in the collective, to build the application, so there are some package

to ease management of contacts, so to describe in the application your organization, and we also have package to extend the EAFS-TIT navigation to build a real dashboard with searches and so on, with predefined searches.

So, as I said, the workflow is very important in the application, because finally it's a basic example. So, yes, we need it to be able to build workflows easily,

and so what we do here is still using the default DC workflow engine, but instead describing the full workflow in XML,

we use another package that is called collective workflow adaptations. So, the point is you have a minimum workflow described in XML, and then you will apply what we call adaptations to the workflow. So, for example, it will add new states or it will change the transitions and so on.

So, that's something we use to design the workflows.

So, still based on DC workflow, what we discover with Plune finally, to build applications, is that most of the tools are already in Plune. So, we use the DC workflow. We were using action XML at that time.

So, everything is in Plune to build applications. Something we added to the DC workflow is what we call a word that will, for example, today a transition may be done or not,

and if not, it is not displayed. But something we added is a way to display a great button. So, instead of not having a button to trigger a transition, you have a button, but it's great, and when you go over it, it tells you why you cannot do the transition.

So, it's something very interesting in some cases because it gives the user an hint why it's not able to trigger the transition. We are simply using the permissions and local rules

that are in Zorb and Plune by default. So, security in the application is very important for this application because it's managing city council and so on, and there are some items that we did to people or salary, career evolution.

So, it's very important that the security is performant to avoid having access to items that you cannot. And there, well, Zorb and Plune offers this by default. So, we are still using also the searches in Plune

with the allowed rules and users portal catalog index. So, out of the box, I would say, all this is available. We just use what Plune offers.

We are just using an additional product that is called Dexterity Local Rose Field that will link local roles to the organization. If you are interested, we can talk about it. And so, what we did last year is working on caching and performance.

And all this, again, is in Plune by default. So, we are using Plune App Caching and Zorb RAM Cache

to speed up the application. There is many talks today and during the conference about the front-end. Here, it's more about the back-end, how to have a performant back-end too. It really changed the application to add caching

and we did some benchmarking and we have now, even on big organizations, response of less than one second for any page.

And we are still not using Solr or Elasticsearch and so on. So, still out of the box. Neither we are using Varnish. Not Varnish too. We are using Plune App Caching and Zorb RAM Cache and it's very powerful.

In fact, by default, Plune is doing too much, finally. For example, when I have this here. So, here are the metadata that we use by default. There are 36 metadata in Plune 6.

Here, we have 59. But a problem we see in Plune by default is that when you re-index an object, by default it will update every metadata. So, even when you re-index a single index,

let's say re-index the created index, it will, by default, re-index every metadata. And metadata are not always data stored on the object. There are sometimes computations like, for example, to get the last command date,

the recent adaptation of the object to get the discussions and so on. So, updating the metadata at each re-index is not very performant, so we adapted that to avoid it. Today, I think that we are still using what Plune offers by default.

And our biggest organization today is 1000 users. 500 to 1000 new items created every week. They are in production for 8 years now,

and there are 200,000 items in the element. We are reaching 1 million records in the catalog, still using the default Plune catalog. Yes, it's a 30 GB DoDB with 700 GB blobs,

and it's only using 30 GB of RAM, so we have a default Plune installation, default but optimized and tweaked, so it's still performant, I would say, out of the box.

We see here just a snapshot that we take of the undo log, and we see that there is a transaction every second and so on. It doesn't finally provoke too much conflict errors,

because what we do now is trying to make transactions as little as possible. The problem with default transaction in Plune is that it is too big, there is a full index and so on, and here we try to make it as little as possible,

and we avoid many conflict errors. I will try to think on the... So we optimized to still be very quick with 1 million records in the portal catalog.

As Olivier said, we have 250 organizations using the same application, so when we do optimizations for large organizations, the small are still using the same application,

so we just have to take into account large organizations, and it's okay for everybody. Indexation process was optimized using a default portal catalog, so we still don't go to Elasticsearch or Solr.

There are also other problems with dexterity, old archetypes, but dexterity, handlers, and when you save a form in dexterity,

it's doing some things two or three times, so it's something we solved too. For now, as I said, it's still using Plune 4, so old versions of dexterity, but the problems are still there in Plune 6, so when we are moving to Plune 6, normally next year,

we will try to move all these optimizations to the default dexterity, if still necessary. So, we are using Prune App Caching, it's a very impressive tool to speed up things,

even if here we are always logged in in the application, so we cannot use Varnish also, but with Prune App Caching, something that is interesting is that extra-share queries are not cached,

so you may propose a page that are cached, and some part of the page may be updated using extra-share queries that will not be cached. So we changed to, and we proposed an issue on Jupyter cache,

the default storage has been changed to, because today, by default in Plune, when you have something in the cache, there is a timestamp, and the cache is valid for, let's say, 600 seconds, and after 600 seconds, it is cleaned and cached

and computed again if necessary. What we changed here is that the timestamp is updated the last time the cache is used, so instead, a cache leaving for 600 seconds, the timestamp is updated each time the cache is accessed,

so it continues to leave longer. Yes, the RAM cache storage is an adapter, so we changed this, and we are discussing an issue on subprime cache to move this to the default storage,

or to propose this as an external storage. We are still not using the storage also, so it's just a default application. As we said, we have dashboards in the application, so it's a dashboard with many things that are displayed.

What we try to do is to avoid conflict errors, is to do as small transactions as possible. For example, what we have here is inline editing of rich text, so instead of editing the full form,

you just edit one single rich text, and then you change, you save, and it will just re-index the searchable text, and not all the metadata, not all the fields, and so on, and this avoids conflict errors.

What we have here, yes, we have also the possibility to display several face-ditch searches on the same page. We are using pop-ups and so on to avoid, to speed up things, to avoid computing too much things. Yes, that's a common...

So something else by default in Plurin that is very interesting to build applications is the ZCA. So we are using it very much at the beginning, but as we said, 250 organizations using it, it becomes very complicated with the legacy to manage all this.

So what we do now is to provide and to propose to the web parameters. So we have a huge configuration panel with many parameters, and so we are using ZCA

only when necessary or for low-level adaptations, but for the final client, finally, we propose parameters in the UI, and yes, that's very... That lets us manage so much organizations

with different needs, and yeah. So here, for example, is a page in the configuration with several parameters. Something else too that is out of the box in Plurin

is a process to... The first version of the application was using Plurin 2.1.2. We are now in Plurin 4.3.20. We are moving to Plurin 6, obviously, and most of the content types are moved from archetypes to dexterity.

There is two content types, I think, that still need to move to dexterity. We used in-place migration from Plurin 2 to Plurin 4, so we already have old database. So the oldest database is 17 years, I think,

and it was in-place migrated for Plurin 2.1, 2.5, Plurin 3, and so on, and it's still working without problems. So yes, I know there is some fight between in-place or exploit import,

but we are using the in-place migration. I think it's working very well, and what is interesting is that it's there in Plurin by default. So it's a mechanism of Plurin that we use simply because it's proposed,

and so I think, again, this is something in Plurin that lets users be confident and you are able to build huge applications because you know that there is a migration process that you can use to make it evolve.

So I will let, continue, Olivier. Just to summarize some key points about Yanderebe. We built a monster application, which has got even monstrous over the years, and today it's really huge.

So we are facing quite a lot of challenge and also new realities. This application is here to face a new reality, a decision to bring the politics and stuff that decided inside the municipalities back to the people because, you know, you vote for someone,

you elect a bunch of people, and then you don't care at all. You let them go and you don't feel like it's your stuff, you know. And this is what they are bringing back, trying to bring back with this platform. I will do a quick demo if it works.

I think this one, okay. No. No. Okay. So this is the portal. This is the front page of this app. And you can select one municipality.

Like a big municipality like Liguage. Up, up by this hard. Okay. And then you have, you know, this is a constant meeting. It's not already happened, but it's already shared with the people, you know.

So you have the access to the decision beforehand. And so if you are interested in it, you can go to the console because it's public, anyone can go. And you can read it, you can consult it, and so on. So basically that's the idea of the portal. There is also a big difference with IaDelib.

First, it's Python 3 and the latest version 5.2. Second, it's absolutely not the same target user. This is for everyone. And IaDelib is really like a business app for business people in the municipalities and so on. So IaDelib is quite more, way more simple.

Again, standard Plune, a few add-ons. That's like, that's how we like it. Just, you know, Plune provides enough by itself.

Like Gautier said, even in monster's IaDelib, we just use Plune without any varnish, any well storage, not just Plune. And the data comes from IaDelib, goes through deliberation.de. But not all the data because, you know, there is something that's called GDPR.

And it's not enough for the customers because Anonymosity is great, but they have a need that you cannot even know who they are talking about, at least not before they are discussing it in live. So sometimes it's quite complicated.

About the web services, in IaDelib we customized, we use Plune REST API, but we had to customize some endpoints because, you know, there is always some little thing that needs optimization and we are also providing these endpoints to, you know, other apps that are third-party.

And so it needs to be really clean, really, you know, strengthened and really precise. And I think that's it. Conclusion, I think I already did it, but, you know, Plune Toolbox, very great.

We are optimizing really some little stuff because we have huge database and thank you community because everything works so well. Does anyone have questions? No? Yes? Mike?

Can I repeat the question? So one slide you left Vegas in and out, you mean there are workspaces in and out or staging? No, it's a web service in and out. Web service in and out. Yeah, so Fred was asking this. We asked in one slide was web workspace,

but no, we put a web like web services. Another question? Yes? Yes, everything is on GitHub.

So we are asking if everything is open source and so on. Yes, everything is on GitHub. Everything is, you know, public and you can use it if you want. Anyone else? No? So I guess that's it. Thank you.