 I think we're going to start. Hi and welcome to our showcase. We are very glad to have you here. Today, we want to give you some insight in the commerce project we recently launched. We are Mario Thieler. I work as a trooper developer for UNIC. And this is my colleague, Kai. Yeah, he works apparently in the same company. And yeah, he did the project management on this project. Thanks to Daniel Manow Smith for the project, for the photo. This was taken only two days ago. Yeah, unbelievable. More two days of TrooperCon made out of us. So this is what we're going to show today. This is our roadmap. We're first going to show you the business case and the customer vision of what we did. After that, we will show two workflows in detail on this platform. Then we sum things up a bit. And there should be time for questions afterwards. We play a bit kind of ping-pong. Kai is talking about the business topics. And me, I'm talking about technical stuff. OK, so the business case. There's a vision of the platform, which is in German because it's a Swiss platform, von der Gefahr zum Produkt, which roughly translates to hazard-driven product selection. And you will see now why this is the case. So this is a marketplace for safety equipment. And our customer who we built this platform for is a Swiss insurance company, Suva, one of the big insurers in Switzerland. And they provide a marketplace, but they don't sell products themselves. But vendors do. There are over 60 vendors on the platform. And this will have some consequences. We will see later what we did in this project. The products that are sold there are, for example, preving masks, safety shoes, and stuff like that. And those are highly specialized. And we will also see this in the workflows. There are over 10,000 products. We'll give you a rough idea with 50,000 variations. And because the products are rather specialized, we had about 20 different product types that we need to manage. The platform is multilingual, typical in Switzerland. So there is German, French, and Italian. Because this is a marketplace, there are very different requirements from the different stakeholders. So on the one hand side, there's the Markplus owner, so Suva, the insurance company who provides the platform and the team of Suva is also maintaining the basic settings and the vendor settings and stuff like that. But they don't sell products themselves. But because they are an insurance company, they really strive for highly accurate product description because they want to protect the end clients from the hazards that they may face in their work or private life. So this also means that the marketplace owner controls the product for the product information before they go online. We will also talk about this later. The vendors on the other side really create the products on the platform. They sell them. They ship them their own products. And they just want a modern UI with good workflows so that it can work with the platform. And they need some further statistics and stuff like that. And this counts that they really can work with the platform. The last big stakeholder is obviously the customer. Those are mostly small to medium-sized companies which need products for their daily work where they have hazards. And for example, I don't know, build a house and then they need the safety shoes for their workers. Yeah, they just want a good shopping experience over all the vendors on the whole platform. OK, so to give you a first idea of what this looks like, the final product, this is just a short intro video on where you can see the home page. And then we navigate through one to one of the categories where we see a large faceted search. And this search is really to find the right product for the hazard that the customer is facing. When we see here on the detail page, we have some product description, some images in the product, further safety information about the product, link products, which we will also see later, and some information about the vendor. And the add-in, obviously it's a shop so we can add it to the cart. Sometimes there are link products that you have to buy with it. Yeah, and then we have the checkout workflow at the end, which is also special, but we will not cover that in detail today. OK, so yeah, let me give you a high-level impression of what we needed to build. So there are multiple stores, obviously, with access routes. I mean each store owner should only be accessed his own store. We have these variety of product types and product variation types. We have a custom product creation workflow. We have to build. I'll come to that later. We have an advanced publishing process with different states to ensure there's no bad product data coming to or gets published. We have to create back-end access for vendors, customers, and platform administrator. We have an extended faceted search. We extended the facets itself with additional information in the front-end. And we did a migration for all the products, but this is not part of this talk today. So to achieve our goals, we used TruePile. This was the right ecosystem. Our key advantage was its extensibility to build all the things on top of TruePile. It was sure a mix of Contrip modules and custom modules we were using. From Contrip, we used Commerce 2 as a base. It was version 2.10 when we started. Commerce 2 did the heavy lifting. It was a solid base. It gave us product types, doors, orders, a checkout process, and the whole commerce ecosystem. We did not use the Commerce marketplace module. It wasn't a fit for us. It was too far from our case. We checked it out. We also used the state machine module for the publishing flow, search API and facets, for sure, to name just a few. Now let's switch over to the product creation workflow. OK. So like we said, I will introduce you shortly to the requirements that came from the customer. And then Mario will tell you the details for each of the steps we will see. So like I said, the requirement is really that we have accurate product information because this is the most important thing on this platform. That we have a step-by-step process, and it's not too overwhelming for the vendors. And at the end, there's no specific training needed because each of these vendor usually has multiple persons. So we're talking about over 100 editors who need to create products. And the product information should be accurate. So this is like a mix that we had to take into account in the whole designing process. So what do we want to achieve in the product creation workflow? And overall, we want to create multilingual commerce product entities and its variations with translations, additional attributes to classify them. And all of this should happen in a multi-step process. Together with our UX team, we identified seven steps that are required to create these products. I give you a short diagram from our internet documentation. First of all, we select the catalog entry to determine the product category and the product type itself. Then we fill out base information for the product, manage all the variations, add them, delete them, and so on. And add filter attributes like facets, translate everything, add additional products, and provide a preview. And all of this could only be achieved by using custom forms, entity forms, entity listings, like built with list builder. Yeah, we check the conflict landscape to find the suitable solution for this multi-step process. There was nothing really around. So yeah, we built this in a custom way. Now, what we did was creating custom controller that handled all of these seven steps. And that extended the form controller from the product form controller itself. And this controller was responsible for all the actions for stepping forward, backward, and so on. OK, so like we've seen, the first step is the category selection. So we have different product information depending on the product type. So it's important before we can have any form for the product that we know which product type it is. And the requirement was that there is like a logical, hierarchical structure. This is based on safety norms that are out there that they need to follow and that they find the right product in the right category. So yeah, you can imagine the safety shoe has really different attributes from safety goggles or breathing masks. So we needed to take this into account. So the customer should select a product category, but not a product type. This was a goal from UX perspective to achieve that. We created a custom ejectified form that behaves like kind of hierarchical select. Someone knows that module, but it's a bit different. The custom hierarchical structure itself came from a vocabulary tree. And terms in the deepest level can are referenced to a product type. And so we could achieve, like we could say, eye protection category references to the product type classes. And this is how it's selected. So there's a video. So first of all, the user logs in. So this is the store administrator, so a store owner. And he has like a dashboard. And he adds a new product. I have to excuse a bit. It's in German. We could not make it to translate it back to English. So I will explain it. So now the store owner navigates through the category and decides to go with a breathing protection mask and steps over to the next page. Because now we know he wants to have product type inhalation protection. And then he's able to fill up and step through the product details. For the product details, like we said, different product information, depending on the product type needs to be filled in. Additionally, a requirement was that for each field or for each section of the forms, there need to be additional information to support the vendors who are sometimes not the expert or not so tech savvy. So there was the requirement that we provide relevant information to the vendor in each field that they know what they fill in here. So we had like 20 different product types. And we had to bring them into this multi-step process. So we decided to go with custom form modes for each step. So each product has a form mode for product details or for step two. And so we are flexible enough to fulfill all edge cases. The store itself is hidden there in the product category because we know that already. Yeah, and this is how it looks like, actually. On the left-hand side, there are some information boxes. We call it field notifications. We will come to that later. And yeah, this is actually a product entity form, like it's beautified or styled. You fill up a title, a description in the brand, upload an image. And these are the minimum required fields to create a product entity. Everything that's coming up from now is additional information. OK, so now we have a product. But without the variation, we can't sell it. So the next step is the variation. Also here, depending on the product, we have a variety of different fields like before. Also, the additional information is back on there. And we had to deal with a mix of order-relevant data and just additional information. And some of these are like free text fields. Yeah, the order-relevant information is, for example, color or size, which are relevant to determine the variation. And the additional information is just something that we may show to the customer. So for example, the vendor product ID or something like that, or we show it to the customer, oh, it's important for the vendor themselves for their product management. Step three is a process on its own. It's not only a single form, but it's multiple routes that go to step three. That means we have listings of variations. We have adding new variations in this step, duplicate existing variations, edit and delete them. We used auto SKU module here for some, yeah, just like commerce internal reasons, because the SKU must be unique. And we cannot guarantee that each store has its unique ID on their products. And we added the possibility to insert free text attributes, to not select the attribute value itself from a list, but to enter it by hand, like let's say you have a color, a new shiny color, light green, for example, that is not in the list. You could add it to the list itself. The special thing about it here is that these are determining a variation. That means if you can make out of these free text attributes, you can form new variations that are relevant for the order and can put into code. We print out here in this process the translation completely because they are covered in a single step in a translation step. So this is the whole process of adding a variation. So we enter an article number, the SKU, so our custom SKU, the price, the tax rate, the order quantity, the order unit, mandatory fields, and availabilities, and some more information. Now we press the button Save and Duplicate, and now we have like duplicated the first variation. And now we go to the next step. We order some information and save it. Now we see the listing. We should see the listing exactly. And we have these operation buttons. We start this list. You might know them from the back end. And so now we have like two variations. They're untranslated. And the next step is adding like filter attributes. OK, so the filter attribute, we mentioned that before, is more related to the use case. So these are really the safety relevant information. For example, for safety shoes, which sole you have on them, or for a previewing mask, which filter needs to be in there to protect from the hazards that the customers are facing. Those are not for all product types because some are not that specific and just are normal products and don't have these filters. The filter attributes are actually then grouped into filter groups. And the special thing here is that the attributes and the groups can have logical relations to other attributes and groups for, yes, to include or exclude something. When you select one of the items, then something else is excluded or included based on some rules that are configured. This was the most complicated format all in this process. We heavily used Ajax forms and actions here, like the native ones provided by Trouba to achieve like edit, save, and reset stuff. Filter groups and filter entities are custom entities with custom widgets. They have dependencies, as Kai mentioned, and hierarchies. The customer also requested a widget that contains a mix of radios and checkboxes, which was weird, but there was a use case to do so. And each checkbox itself had some additional information to show in this tooltip. So this is how it looks like. So this is the tooltip, the additional information of this filter attribute. It's selected. Now we see, yeah, there's only one option possible for multiple use, because it's a mask with integrated filter that the one used. Now they use full masks. And now we can proceed to the next level. So this was very quick, I know. But it should simply give you an impression on how this worked out. So the customer itself, they will spend a lot of time in this form to add new, the correct product information, because this is required for finding them and to display them on the product detail page with the right information. So now we head over to translations. Step five, the translations. So like we mentioned, the marketplace is multi-language, three languages. And each vendor is required to provide some subset of this, all of them in their contract. So there's maybe a vendor who just enters the stuff in German. But there can be all three languages put in here. So if you know the backend of Drupal Commerce or the backend of Drupal, how they handle translations, this is not very special. It's simply like styled. So this is also like a multi-step, a multi-action process where we list and edit and delete translations. And yeah, this is how it works. You add the translation. This is exactly like it looks in the backend of Drupal. So yeah, simply add the French translation. And that's it. The sixth step is spare parts and combination products. So spare part, I mean, is pretty obvious. Each product can have a spare part that can just be linked. But there's the other thing that's combination products. That's for example, if you have a mask, then there is the filter on top. And this combination then prevents or protects the customer from the hazard. So the combination product is not a spare part, but something you need to have with the product. We created a form mode here with entity reference auto-complete widget and some field groups. You will see that. There's nothing special so far except that the auto-complete widget only finds product in the current store or in store the user is in. And the combination product field becomes mandatory based on filter attributes in step four or even not. So it's like, for example, a precinct mask can only provide a specific protection level with the right combined filter. So this is the reason behind it. So yeah, this is it. So yeah, this is this auto-complete widget there. And as you can see with the asterisks on top, it's marked as mandatory. And now we are in the preview. OK, step four is the preview or review step. This was quite important to the customer so that the vendors see what the product would look like before they finish it. So this should be a realistic preview with almost the same design as they will see it in the front and for the end customer. The preview should consider different languages and different view modes. And yeah, Mario will explain how it is. Yeah, this is the last step before products goes into this approval process. Actually, we're doing nothing else like looping through all the languages and render the product in teaser and full view mode. We had to disable some buttons, some like add to code so it cannot be checked out by accident. And what we also do is perform a high level integrity check on this product data. Like, does the product has variations? Are there any filter options for the product set? Have all contract languages being covered or is there a combination product, a required combination product already filled up? If all the validation passes, the product gets the state needs review and it's passed over to SUBA, the marketplace owner, and for the review process. In this step, this is the preview. You see the teaser and the full view mode there. Add to code is disabled. Yeah, the tabs are still working. Yeah, below there is the French translation we created previously. And on top we see this orange step five translation is missing, warning. So it cannot pass over to the next step. So obviously, this door is required to have three languages. Yeah, they had some additional information and saved this translation. Now when we go back to step seven, yes, you can step over some steps or choose them manually. Yeah, you get all the languages and now you can pass it over to get controlled, to get reviewed. So it's actually a product listing, but this is not covered here. So now I'm going to show you or give you some insights on the product review workflow. OK, so the product is now ready from the vendor side, but it needs to go through the control of the marketplace owner. As we said before, the accurate product information is most important, so this is why this step happens. The marketplace owner controls the product and what is an additional requirement is that they can mark mistakes and give some feedback why this is wrong. So this is now where the stuff that you saw on the right always comes into place. The main goal is to decide whether a product is publishable or not. We used a state machine for that. We gave that favor to workflows because it was more handy to us. What we also had to do is to facilitate the communication between the marketplace owner and the vendor and make this communication very efficient because otherwise they cannot have like emails or phone calls to do this. So this happens in place in the product. First, let's have a look in the product publishing flow. This is actually what our state machine YAML file is like with all the transitions. So we have it like first, what we see the product the whole time was in draft and edit mode. It was offline and not published. Then now when all seven steps are passed and the validation passes, it gets over to review. And now it's in a marketplace queue. This marketplace owner decides that the product gets rejected and it gets back to the edit mode to store owner gets an email about this. He gets an email on every transition in the states. And if the product is approved, it gets published and is online. If the product, if the store owner itself wants to edit this product again and edit some critical fields, the product must be disabled again. So as long as the product is online, some security-relevant fields are right protected. And yeah, there's also this unpublished state with the products outdated or so you can remove it. So the next slides are about the review process and how we facilitated this communication between these two stakeholders. So what you saw when creating a product on the right-hand side, there was these boxes I mentioned. They are like yellow. They were white before, but that's a different reason. And these boxes give some advices to the store owner when they fill up products like rules. What do you need to think about when you fill up these products? For example, the name has to be self-explaining. So add some more information if that isn't the case or do not place attributes or brand names in this title. So these fields or these information, these are also custom entities we created, these field notification entities. And they are attached to the field configuration. So this is the view of the vendor. And now we can switch over to the perspective of the marketplace owner. The marketplace owner itself also has this view, but he has a checkbox where he can say, OK, this rule is not passed. I check it. And once this checkbox is activated, there is the possibility to have in place commenting on this. So they check it and say, OK, you violate against the rule. There's obviously UVEX, which is a brand name inside the title. So this net needs to get removed. So they check the box and the product gets then back to the draft state. So once this happens, there is some communication taking place. So the blue ones are like the server or the product, the marketplace owner. And the gray ones are the store owners. And they say, OK, this shouldn't be in this category. And they say, thanks, Fin fixed. Yeah. And this is how we facilitated this. And we used, because this checkbox or this text area on top, this feed notification is content entity. And we could easily connect comments to these content entities. So this is basically the comment workflow from core. And the last functionality we put out of the review process is the quality statistics. So every time one of these checkboxes is enabled and there is a mistake, the vendor sees this on a dashboard, what was rejected, what was the problem. And he can try to get better and more efficient. And the product will pass the quality control faster without going back to needs work and stuff like that. For the server, so for a server for the marketplace owner, this is also handy because they see where they may need more information in the whole process to make it better. And they can do this on different levels for the whole marketplace on each vendor or even down to one user. OK, so those were the two workflows we wanted to show you. A short conclusion. There's a lot more that we did not show here. And we didn't have time. So like Mario mentioned, there was a rather big migration happening from a Microsoft SQL database which was fun, the small project in itself. We have vendor stores. So this means each of these 60 vendors has a unique URL that they can use. And when a customer comes in via this URL, the whole marketplace is like a small, is a little bit change that it only shows the product from this specific vendor. And out of the box, there's a vendor store that they can use and communicate to their customers that only shows their products. The checkout process, like we saw a small snippet before, is also changed because of the requirements. Each of the stores need to have their own checkout and own payment possibilities. And we put also sales statistic for the vendors into the marketplace so they can download their most or they can find out what products were sold most and stuff like this. We did this for the customers or what was the big improvements for the customer. The first one is that they got rid of their custom implemented shop. And we use now a triple state of the art framework and a really new, refreshed design. The production workflow was definitely one of the biggest changes for them because before it was one big form with confusing buttons. And now they have a clear, designed workflow. And they obviously benefit from the open source community. If they need changes, this is way more efficient now when we can look for contra modules or in profit from all the stuff that Trupal offers us. Some project details, as I'm a project manager, I have to say two words about it. We went live with this almost half a year ago. We worked for 10 months, 16 sprints on this. The core team was nine people, four of them, Trupal developers back in the front end. And last but not least, community contribution, always important. We have been a nominee for the Splash Awards on Monday. Sadly, we did not win our category. But yeah, nothing we can do about this. We published a case study on Trupal.org. If you want to find out more and also about the stuff that we did not cover here, you can find it on Trupal.org. We contributed to some modules that Mario mentioned that we used and represented this case or parts of this case at the local Zurich user group meetups and discussed some of the stuff with the people there. OK, thank you for your time. Special thanks to Nico, one of our colleagues who did all the videos, the screencasts. And now we have a few minutes left for questions. Feel free to ask. Yes? We can hear you, but I don't know if the rest can. Yeah, you're moving to be embarrassed in the mic. You can speak louder, and it would be recorded there. OK, so hello, whole project. I always admire custom solutions. But I always fear to leave industry standards, especially for shop manager in that case. Can you tell a little bit more about the shipment process work and all the return handling and stock management and all those things that you also have in this shop solution? So the case here is that we don't have to deal with it, because all this happens at the vendor side. So each of the vendor has his own back end, and they don't handle this in Truppel. So they do all the shipping and return, and it's not covered on the platform. This is just due to the history of this platform, that it was never the case also in the solution before, and that the vendors are really, really different. So some of them are just one person who does this all in Excel or something like that, and some of them are like 20 people do this, and they have other back end systems. But they are not connected at the moment. We are talking with our customer if we do this in a later step. But at the moment, this is totally out of the marketplace. You had to integrate with the vendor IT systems? No. Did you switch off the software? No, we did not. So this is all the product creation, and all the stuff that comes afterwards is done by hand by the vendors. There's no integration into any other system, apart from the migration at the beginning of the project. Which was the hardest implementation in this project, because I have a bad experience with Tupac Commerce. I try it sometimes, and it has a lot of unfinished things. So actually, the hardest part of this project, from my point of view, was the filter page stuff, and this was not related to Tupac Commerce at all. We had quite good experience with this, because it has a very stable API. So we had no problems with that. So there was a change of how product variations are handled. I think in 2.11, there was a change where you did not necessarily need inline entity forms to create variations on the product. And this helped us to create this multi-step process. And actually, I do not have, we had no problems by commerce itself, so this was not an obstacle. We had different difficulties, like the migration with MS SQL, or with these custom filtering workflows, but not with... Yeah, so my colleagues are nodding. So it's... I see you use the state machine model there. Have you considered working with workflow, for example? Yeah, so we compared them. And as far as I remember, workflow was a bit more back-end user-oriented, as far as I remember, back-end UI. But this is not... We didn't want to create new workflows dynamically and arrange them or so. Our workflow was very clear, and the state machine gave us a clean API. I'm not sure if it's more lightweight than workflows, but it was more handy to our case, and we could easily set up these dates and act on transitions, and this was exactly the perfect fit for our use case. For example, when we do a transition, send an email or so, and this was exactly what we needed in this case. So why did you take the products offline if some critical fields are changed and did not add a draft and leave the product online until the draft is approved? Yes, we discussed about this. So the first thing is that the requirement was really clear from the customer that the vendor is not allowed to change anything safety-related. So he can change the price or the availability without taking the product offline. But for safety-relevant information, it had to go to the approval process again. Like you said, we could have done the revision or something like that, but this was just due to timing and budget constraints that we did not implement this. It will come at a later state, but not yet. OK. Yeah? How did you manage the construction of the catalog structure with filter attributes and filter attributes, values, entities, customer entities, you said? But how does it move around in a year? Or is it easily administrated? Or because for me, it's very different in Drupal with the product types like the DAB model in magenta which is more flexible about this. So basically, the product category is taxonomy. So you can easily change, and always the lowest level has a product type connected to it, the taxonomy term. So this is the relation between the two. What was not implemented, and we are not sure if the customer really want to do it, is that you can change a product type after you created the product. This is some, we should do a little migration then if this change and this was not implemented. All the other stuff, the filters and field notifications are entities which are linked to the product type. And so, yeah, you can change every piece of it. So it's flexible? Yeah, it's quite flexible. I think we run out of time. OK. Thank you for your attention.