 Hi everyone, we're here to talk about Drupal and Wolves' Code. This is what we're going to cover in this short session. So we'll have a quick introduction, a little bit of information about what is Wolves' Code. We'll look at a GovCMS proof of concept that we completed around Wolves' Code, some of the process behind Wolves' Code, and also of course the most important part, given this is a Drupal Meetup, is Drupal's involvement in Wolves' Code for CELSA projects. And then we'll have a Q&A at the end as well. So just a few quick introductions. So my name's Philippa Martin. I work at CELSA Digital doing Wolves' Code and also as a content specialist. My work in Wolves' Code covers both business analysts and also content. Hi, my name is Sujiko. I'm a technical manager at CELSA Digital. In this particular project, Wolves' Code project, I was working as a tech lead and a developer as well. So the Drupal part of the Drupal integration with Wolves' Code was something that I focused on. Okay, so just a little bit of background or context. So basically CELSA responded to a GovCMS request for expressions of interest for a digital experience platform solution. There were six potential user journeys listed and one of them stood out to us in particular, which is the stage where a citizen is figuring out what they need to do to either access an entitlement or to comply with a government policy or a legal requirement. The reason why this stood out to us is because it could be solved by Wolves' Code. And in fact, at the time we were already working on another Wolves' Code project that specifically looked at codifying New Zealand Social Security Act so that citizens could answer a few questions to find out what benefits they were entitled to and how much they should be getting as well. So let's talk a little bit very briefly what is Wolves' Code. So Wolves' Code is basically taking legislation, regulations or policies and turning it into machine readable code. There are several benefits that this represents including reduced ambiguity, making it more accessible, reusable, easier to manage, transparent and also using it to inform policy. At the moment in this space in terms of the Wolves' Code dev tools, OpenFisker is the main tool. It's used for Wolves' Code. It's lightweight, modular and scalable Python-based Wolves engine. It's open source, which is what we like. It's also been developed by the French government in 2011. So it's been around for a little while. And it's now used for Wolves' Code projects in New Zealand, Australia and Canada as well as other jurisdictions and of course France as well. Just briefly we'll look at a very high level of the solution architecture just in terms of where everything fits. So obviously at the top of this diagram here we have our end users and then they may be coming in to view the Wolves' Code or find out information via a website. Mobile apps, possibly voice devices of some sort. And then those apps or user interfaces are talking to both Drupal and OpenFisker. So let's have a little bit more about a look at this Wolves' Code for GovCMS proof of concept that we did. So we were successful in our expression of interest and GovCMS asked us to create a proof of concept. Specifically, they wanted us to look at COVID vaccinations. So they wanted us to help citizens understand if their COVID-19 vaccination status is up to date. We looked at the main journey was, am I up to date with my COVID vaccinations? We also wanted to look at another journey that would demonstrate how state information could also be brought into a Wolves' Code system. And to do this, we also added a journey, do I have to be vaccinated for my work? So what we've got on screen here is final product. This is two websites. I'll look at one of those in a moment that look at COVID vaccination in Australia. The main website contains both user journeys, so the one about am I up to date with my COVID vaccinations and also do I need to be able to, am I up to date to work? But then we also created another interface. In this case, a hypothetical website dedicated to our First Nations people. The First Nations website contained information about the user's Indigenous heritage and then tags that user a priority booking when they're transferred to the booking system. So let's take a quick look at one of these websites. So basically, these are some examples of the sorts of scenarios that people could be asking themselves. So perhaps a 55-year-old adult who's had five doses or maybe their 32-year-old adult who's had three doses, a parent looking for information for a 15-year-old immunocompromised child or a parent looking for information for a four-year-old. So I will just... Can I actually leave my glasses? Okay, so can everybody see that website at the moment? Thumbs up. Okay, so as you can see, this website was actually just created to show what a coronavirus-dedicated website might look like. But it's actually only these two links here that are active. I'm not going to spend a lot of time on this because I know given we're in a Drupal meet-up, we want to get on to the Drupal stuff. But just to give you a quick look at how it works. So given a little bit of introductory information, then we can press Start. We're showing where we are in the journey. So the first thing we need to enter is our age. I'm going to put what you do. And then it takes you to information about your health. So if you're immunocompromised or not, let's say no. And then it's got information about your, how many doses of the vaccine you've had. So in this case, we'll say two doses. And maybe the last one was, let's put it quite recently. There we go. Okay, so if we hit Submit, that then talks to the open fiscal and since you will talk a little bit more about how that works in a moment. But it just lets the person know you're currently not up to date with your COVID-19 vaccinations. I give some information about how many doses they should have had, what the recommended vaccine is based on their age, and also some information about the likelihood because they're over 18, they could also access these other three vaccines. The information that's highlighted in yellow is information that's being returned from Open Fisca and Drupal. So take a step back now and look at the actual RSS code process. So how we get to that point. So basically we've got a few different steps involved. First of all is the rules analysis and mapping. Then we go into Open Fisca configuration and coding. Then we start using the Drupal Open Fisca module and the Drupal web form and also setting up the results. So we could go into each of these in a lot of detail, but we're not going to. I'm just going to very briefly cover rules mapping. So generally we would initially do some sort of extraction of the rules in plain English. In this case we looked at it by a person's age given that was how the COVID vaccinations were working. Then we created a high level model that captures entities, any legislative requirements, eligibility logic and calculation logic. So obviously that doesn't apply to this one, but more calculation logic in terms of, for example, if we're working on how much Social Security benefits someone should be eligible for. From there we go into the process of actually codifying the rules. So we create test scenarios, create entities, create parameters, create variables, including the input and output. Now we're getting into technical stuff. So you know what that means. I'm handing over to Suji. So this is the rules for configuration. The rules for configuration actually goes into OpenFesca. And in OpenFesca we start with the entities, parameters and variables. And variables are of two types. One are the inputs and the second one is the output. As clearly seen here, the output are actually calculated. So in the flow that we saw where Philippa was, what Philippa was showing, each and every one of the workflows that you saw, they were actually, whenever there was a submit, they were going back to OpenFesca and coming back with a response. So as an example, in the first one, it asked for an age, it went to OpenFesca and asked what is the maximum, what is the minimum age. It checked that. So if Philippa had put in, for example, two years, it would have come back and said, no, you're not eligible for a vaccine. So that is how these things are done. So entities, parameters, variables, inputs are defined in OpenFesca, output are calculated output. And Drupal basically just makes API calls to OpenFesca with proper, with the required parameters as well as the variables. So again, I'll walk through these very quickly. This is basically essentially around the OpenFesca. This is an example of a test case that was created in OpenFesca where we have the scenario is 10 in a row with two vaccine doses, whether they are up to date or not. And then we have a period, we have the inputs and then we have an output, calculated output. And this is an example of under configuration. As you can see, this is a Python code because OpenFesca is Python based and rules can be calculated for different entities, now there are different entities in OpenFesca. Some of the entities can be person, persons, household, companies, et cetera. So in this case, the entity was person. And this is another example of a root code configuration where a parameter is being defined. So the parameter is the age of eligibility and it has various attributes like description, and metadata, and values, et cetera. The last part of the root code configuration is the variables. So we create input variables. So for example, again, the flow that was defined, the first input variable was age. The second input variable was are you immunocompromised or not? So if you look at the second number here, immunocompromised disability, that was the variable that was used in here. And the third before that we had, it asked two questions which were around how many doses have you had and what was the last vaccine dose. And these are the two variables that were taken as input. And once we have the inputs, we have the variables, we have the parameters, then the calculation actually happens. So in this example, we're showing you the calculation of the vaccination update and then it has different variables. So that was an open FISCA part of it. Now let's try to see the Drupal in the puzzle here for making sure that Drupal is able to talk to open FISCA and get relevant information, send relevant ABI calls, et cetera. We went ahead and created a custom module. The name of the module was from FISCA because we are not too intuitive when it comes to naming things. So essentially the concept can be spread into two parts. One is the rules content and the other thing is the related content. So the aim of using Drupal was so that we could make the editor experience as painless as possible and maybe the second reason was because we know Drupal. We used web forms because then we could easily ask questions and tailor our journeys. And we also went ahead and so even the rules content is actually divided into two. One is the creation of the web forms which asks for things. And the second is that we went ahead and created a content type which said, okay, this is a web form. When it is returning with this value, we go to this node. When it's returning with this value, we go to this node, et cetera, et cetera. So that is how we were able to curate our journeys. So in the example that Philippa took, the first web form was fairly straightforward. It just asked for the age. But when the age was sent over to Fesca, the return value could be either eligible for a vaccine or not eligible for a vaccine. So the node associated with this particular web form said if it is eligible for a vaccine, then go to the next web form. If it is not eligible for a vaccine, go to this particular node where in Drupal we had put a content, hey, you're not eligible for a vaccine because you have to be minimum of this age. So that's how we manage the whole journey that we just showed there. Just working again on whatever I just talked about. So step one was how old are you? Whenever we press submit or next in this case, it went to open Fesca, came back with a response and based on that response, it would either go to step two or it would go to another page and say you're not eligible. If you're eligible, it will go to step two and it will ask you, are you immunocompromised? The reason why we asked that is because the rules for immunocompromising people change the vaccination rules. And in the next step, we are asking how many doses have you had and what was the last date along with all the data collected earlier is sent again to open Fesca and based on the return value, we either show something like congratulations, you're currently up to date. Or in the case that Philippa showed, for example, where it said you're not up to date, you need to have three doses, go ahead and book your third dose. So how did it actually work? I'll just show you some screenshots and then we'll probably go to the website and I'll show you the actual Google backend as well. So the border we created it allowed us to add a few things. Number one was we created an open Fesca journey handler which is basically the code that defines where you're going that massages the input since the API calls receives the API responses etc etc. So that is what we have so and that is what we associate with the web form and the second thing is that in the web form we're able to define the, we are able to define that yes, we want this web form to be open Fesca integrated and we can also define the end point of open Fesca. So if you look at this one this is the open Fesca endpoint. Now the moment open Fesca endpoint is defined how does it help us? It basically helps us in this way. So if you go to, if you see the screen this is our web form and when I edit one of the fields there I can actually see a new field showing up there which says okay tell me the mapping what is the link Fesca variable and here it gives me a listing of all the open Fesca variables defined on that Fesca endpoint automatically. So basically as an example again the first form the form itself may be something like what is your age but here if you look at the last option there there isn't a variable called age and we can associate both of them so this helps us in marrying the fields with the open Fesca variables and the second part that we talked about was Drupal rules content but before I do that do you actually want to see the web form back in other screen shots it's planetary enough So Chi can you show the web form? Sure. Thanks. And how does the data get into open Fesca also is that like the first set that gets did I miss that bit? Sorry, I didn't get your question. So you're pulling in like variables from open Fesca and Fesca is that right? So they're defined on not quite understanding So in open Fesca the open Fesca just has data, it has got variables it has got parameters and then it has a code for it to calculate which takes the variables and based on the question asked it returns whatever we want to look at I don't remember why Sorry continue on, I didn't mean to throw a spin on me Alright, I'm just plugging in for a second, we are having trouble plugging in just a little bit Yeah, I was going to ask questions while Philippine is trying to plug in. That was pretty much the only question I had I was just curious how it all connects and I liked the interface that you were doing on the screenshot of how you just select which one you want for the rules That was pretty nifty And I should be able to demo that I think that's really clear Alrighty, we are in So Gia just very quickly show you the whole interface in the back end Sorry, this is not my laptop so it's a bit difficult for me to It is a strange it is a strange never mind Okay, so what I do Gia, I'll just show you one of the probably the simplest one and please ignore the messy stuff So the first one is about you and I'll open it in a new day on time just so that we have access there So this was a form that you can ask me about how old am I So let me go to the settings part of it So the first thing that I showed was that we can add a handler and when I click add handler I had an option of adding an openfista journey handler that's how I added it and then when I go to the general part of it at the bottom you get third party settings and within the third party settings there's a section of openfista this is showing up because of our module only and it says okay, enable the openfista is integration, we say yes and this is the endpoint that we can add Now this is also a useful variable because this is the variable that we will be focusing on from whatever return values are coming So openfista tends to dump all the return values but in this particular form we are interested in just one value that is why we are putting that as well in here Now there is another field as well you don't need to worry about that field much and I'll tell you why Let's go to the build part of it before So when I go to the build you can see that there are actually three fields and the submit button two of the fields are hidden one of them is not, let me just edit the hidden field first and the non-hidden field field first So the title is how old are you, the key at the moment is age but the key would have been anything we don't worry about that but because of that integration we have this link, this variable field coming in and this actually pulls in all the variables defined at the endpoint and it lists them So this way we can create multiple fields and associate them with the Fisca variables There are the forms where you don't need to send fields to OpenFisca and that's where you would say excluded OpenFisca works a bit strangely in the sense that it needs all the values to be for each and every call so if you remember when I was seeing what is the return value it needs us to send the return value as well as pause, only then it will send it back So that's why because in that particular field so in that particular field we had set full vaccination age eligibility is the value that we want so we need to add that as well in the web form because OpenFisca would expect that I'll show this to you again So this is a hidden field it has a title which doesn't matter actually and it is actually linked to the COVID vaccination age eligibility So that's how OpenFisca actually works at whatever we want as output also needs to be sent across in the API call So instead of hard coding them or trying to figure out what to send during the API call we have added everything into the web form and then just started using that I can show you another web form So this one is probably a bit bigger web form and again when we are building it we have a few fields which are showing up but a lot many fields which are not showing up The reason is that in this particular fall there was so many combinations and implementations of data that needed to be returned back that we needed all of them So take for example that is this one is COVID vaccination recommendation up to date, are you up to date or not and this one are you eligible for that? Are you eligible for the COVID vaccination? How many vaccines are recommended for your use case? These are all the values that come in back from the API and we are easily able to show them because they are coming in we put them as tokens in our results pages Does that help? Yeah, yeah, thank you Alright Now coming back to our coming back to our presentation again So that was about the web form As I mentioned there is a second part to the rules content and that is that is creating the journey So basically deciding what happens when this value is returned as this, where do we go So instead of again hard coding that we put that power into the content creator So what we did was we created a content type called rules as code, what else And in this one we can actually add multiple rules like this as you see in the screen So it basically says if the variable COVID vaccination eligibility comes as false then go here So we can add multiple rules and it says this one for example if this is true and this is false then redirect to this page If this is true this is false redirect to next page etc etc etc So that way that is how we are defining our flow So in the flow that for the past short the first one was the most simple one So that one basically said if the eligibility is coming through then go to the next web form If the eligibility is coming as false go to node XYZ And node XYZ is the node where we are putting part in sorry you are not eligible and we have also put in some tokens which show what is the eligibility date Again I can show this how this works So when I go to content and I just show content type RSE So because we had 3-4 months that is the number So each web form will have one node of the type RSE associated with it So this is the first one and it says this is about go to about you form and if value of COVID vaccination eligibility is false redirect to not eligible If it is true then redirect to about your health and about your health is a page which has the next one So that is why we put the power of defining the journey also in the quantitative hands rather than trying to you know doing this or something like that and that one was a pretty simple one but let's talk about this one This is more complex or pretty complex So this has a combination of so many variables If this is true this is true go here If this is true this is false go here etc etc etc And these need to be in the order of preference as well So this is how the rules content was defined Any questions by anybody I'm assuming no questions Alright so rules content yes but now what about the related content as I mentioned that with different scenarios we are going to different pages and each of our different pages was different So Philippa had already showed you one of the pages So the Drupal related content pages were fairly simple they were just standard content types standard page content because we have used the theme we have used the default content type that comes with it The only difference there was we were using tokens so that is why whatever you see as yellow here are the tokens that are coming in from OpenFesca So what we did was we were redirecting to pages based on the rules we were making sure that all the variables and their values are in the URL and based on that we were defining our tokens as well and yeah I mean that's pretty much what we did with it Any questions Just going to finish off very briefly with other Rules as Code applications for Rules as Code and Drupal that we've done recently So I mentioned at the start that we were working before the Gubsimus proof of concept came up that we were working on a codifying New Zealand Social Security Act So and that website is now live the first version of Alpha version which codifies four of the Social Security Benefits It's called Benefit Me and basically we fed the learnings into our long term project in New Zealand Benefit Me we created the webform that integrates with OpenFesca to check eligibility for four Social Security Benefits It includes a calculation logic so this is where it returns your eligible for $476 a week whatever it might be and people can find out more about that one at benefitme.nz but it's using same Drupal module and all the same sort of technology and tooling that we set up for the Gubsimus one That is it Any questions? I'm trying to make this question up as I go I said there we go OpenFesca as a rules evaluation engine right What did you find out about what was unique about OpenFesca and when I asked that is why couldn't you just encode the rules engine right inside Drupal or is there other technology that's a better black box for evaluation just kind of interested in that That is a unique question but I would say that's even before the question but I might want to answer that a bit Just a minute Shivana is trying to end up Okay so all these kinds of conversations we were done now OpenFesca is something that was being used by as I mentioned it was created by trans-government it was being used as rules as we could have put that in Drupal as well but we wanted a separate entity a separate API that can then be accessed by anybody it doesn't need to be just Drupal thing we wanted to codify the rules into something that can be accessed by anything it could be for example Alexa integration and if you remember the solution architecture that we had we have had layer which was maybe a website maybe this maybe that so that was the main was trying to differentiate between the two number one number two for whatever we needed to codify the rules Drupal would have been an over engineering thing in the sense that Drupal is a content management system that's pretty much it so trying to use Drupal for codifying our rules would be sort of anti what Drupal is used for yes we could have done it but it would not be a very efficient way of doing it and again this was a POC and when we were doing the POC as well we were also saying is Opencast has a light tool or not we are not too sure but this is something that we picked and it worked for us because this idea about intervention in Drupal except that I could see it being a separate Drupal sort of had this application which could be an evaluation of the bigger discussion it's a totally different discussion we did have those kinds of conversations but to be frank by the time I stepped in we decided that we will be using in fact some of OpenFest was already on where to be developed the way we wanted to but these are the kinds of discussions we had and it was pretty much like this is a POC we don't know what else will work but we know this is working for our requirements so might as well and I guess from my take away from what you presented one of the power of Drupal where it sits once you come back with the evaluation in your example that's when all the auxiliary information that can be managed in Drupal can be presented like we were saying what no get presented but that could be information about Visor or Moderna or all that type of information all managed in Drupal where this given this instance it's just the evaluation engine to bring it back this guy is just the evaluation engine it's not doing it does not come back and tell us what to present to the user it does not come back and tell us what to do next it doesn't do that it's just an evaluation engine we send some variables with some values it returns back some other variables with some more values and that's pretty much it and Drupal is the one that decides what to do with that information so logic and content is separated according to it