Adobe Experience Manager Forms as a Cloud Service: Fast track your development using APIs

Hello, everyone. Welcome to this session, AM Forms. My name is Vijay, and we’re on the Forms team. Let’s take a look at the agenda here real quick. So we’re going to go over an overview of digital enrollment and communication using APIs. We’ll cover our Headless Forms feature and the related APIs, as well as the communication APIs for customer communications. And then that will be followed by a demo from Varun on the Headless Forms API, as well as a demo from Vijay on communications APIs. First, let’s get to know the speakers. My name is Arun. I’m a principal product manager in the AM Forms team here at Adobe. My name is Mysal Vijay, and I’m a senior computer scientist in AM Forms team. I am Varun, and I’m a senior computer scientist at Adobe, working in AM Forms team. Awesome. Let’s get started. So the first feature that we want to highlight here is our customer communications feature, which is going GA in December. It does come with both the use cases addressed, both your on-demand communications for welcome kits, business correspondence, as well as your scheduled communications and batch statements, like bills, anything that you need to send out weekly or monthly in bulk. We will see how the APIs that we are making available can be used to quickly orchestrate customer communications. The other feature that we’ll highlight, and this is at concept stage, so stay tuned for future roadmap dates for this one. But what we’ll share is how customers can use a channel-agnostic representation of a form, so call it headless delivery of a form, and control its condition for a specific channel very easily using the JSON format that is received. They can develop a front-end app, like a single-page app or a mobile app, without requiring any AM expertise. So this is another exciting area that we will share more details on. To highlight these features, we’ll use a demo story here. So we’ll use the weekend theme. At weekend, there’s a team of people who are in charge of digital enrollment and modernization of enrollment. We have Camilla, who is the Forms Practitioner, then George, who’s the front-end developer, and also John, who’s a Forms developer. And not to miss Aya, who is the end customer and is a weekend adventure enthusiast, she’s looking to sign up for the weekend club and also sign up for some activities that interest her. So let’s look at step one. So first, what you’ll see is Camilla, who’s the Forms Practitioner, used the familiar adaptive forms editor in AMForms to create an author of form. But what’s interesting is she can also now save it as a headless representation in JSON format. And with that headless representation, George, who is the front-end developer, can actually fetch that form model in JSON form and use a React component to render that. So he’s completely decoupled from requiring any kind of AM expertise to do that. And he can easily build front-end applications using this method that contain forms or any kind of data capturing experiences for customers. And he can add it to, let’s say, a single page app or any kind of a React-based application or a mobile app. And you’ll see that in the demo. Next, of course, once the form has been published, you, of course, have Aya navigate to the website, to the weekend website. She fills up that form, signs up for the weekend club, as well as some activities like biking or hiking. And then she submits the form and is now a member. What sets us apart as a product in AMForms is not just data capture. It’s not just the initial forms and enrollment. We continue our engagement with the customer through our communications feature, which means you can actually stay engaged with the customer by sending them communications like monthly statements, account updates. In this case, you’ll see how John, who’s the developer, can use a pre-built template and merge data for each customer and send them communications that include a summary of activities they have been doing, like in case where all did Aya go biking or hiking and how much time she spent doing those activities, how much adventure points she has earned, and then what is her credit balance with weekend. Such a statement can be easily orchestrated and built and sent out using our communication APIs. With that, I’ll hand it over to Varun, who is going to go over the headless forms demo. Thanks, Arun, for the quick introduction. So before continuing forward with the APIs and why these APIs are in the mix, let’s discuss a little bit about our developers and how they are working on it. So George is a seasoned content developer who can create beautiful web applications or mobile applications using front-end technologies like React, JavaScript, or any other mobile platforms. Why Camilla designed this data capture? What a great speak. There’s some background noise, if you can speak a little louder. OK. So sorry for that. So while George creates those beautiful front-end applications, Camilla defines the data capture experiences that have been finalized with the back-end team. And together, they publish those forms or applications to their end users. Now, this works correctly for one or two forms. But when they have to work at scale, they have to communicate multiple times and do multiple iterations. But with alien forms, Camilla can create those data capture experience and define those experience separately using alien forms editor. And using the APIs that will be published in alien, she can publish a JSON representation, which is channel agnostic. Doesn’t contain any JavaScript or HTML and effectively enables multi-channel recognition. The form definition also contains the APIs using which the form data can be submitted, validated, and pre-filled for the end user. So all these APIs give George more control over without knowing anything about alien, more control over data. And you can actually create beautiful applications. So we’ll see that in a live demo how this enables George and Camilla work faster. Let me stop sharing. Yes. There you go. Let me know when my screen is visible. We can see your screen, Varun. Yes. As mentioned, George is a seasoned developer, a front-end developer who has created this website over a period of two or three days. So he has created all those React components and defined all those form components as well that will be used inside the product, inside their application. He has done that over a couple of days. But the data capture experience is not yet defined. So Camilla, on the other hand, is working parallel in alien since she has some expertise in alien. So she creates data models. And then using those data models in the backdrop interface of alien, she defines these experiences for their alien. Now, when she publishes them, using APIs, she can publish a list of forms that have been. George can discover a list of forms that have been published along with that, the JSON representation of each of the forms. So let’s see how those APIs work. First, George will write forms that have been published. So he’ll receive a bunch of URLs representing the JSON representation of the form. Let’s take a look at what the JSON representation looks like. And so a JSON representation contains all the form fields, their constraints, and rules that have been defined within the form. And these rules are not included as JavaScript, but they are present inside. And they work within any React content as well. And there are certain data, there are certain URLs, the APIs, which specifies how the data has to be posted to alien or how the data has to be retrieved from the alien. All these things are part of a form definition, including the form, the data constraints, the validation constraints, and everything. And George, as a season developer, just has created an adaptive form component which takes this URL. So I’ll show this component for a while. And then I’ll show you how it works in the browser. So he creates a component which takes a form URL, fetches it, and then converts it, passes the JSON, creates a configuration out of it, and then renders component present in the JSON definition. So let’s see how that works. The URL that George has received, he just puts the URL in his component that he has created. And if you look at the form, the form gets rendered. And now Aya, who is a customer, she can go and fill in the data. And submit the data as well. And in this example, we have shown that an ID is generated, which ID can be used in the backend to see that the data has been actually received in AEM. And this data can be prefilled using APIs that the form had. So in the case of APIs, the form definition contains, there was an API for the fetching the form data. And you can see that the data has been retrieved from the AEM instances. So similarly, we can show you the second form that was received. It’s as simple as changing the URL for the other form. George has received two forms. So we’ll just copy paste the URL of the second form to see if all the validations that were defined in that specific form are working correctly enough. And just go back to that particular form. And we’ll just try to fill up them. And all the validations, all the constraints that were defined in the form data model are being monitored here. Any custom rules, any dynamic nature of the form is also provided in the form definition. And George can use that definition to create these experiences as well. So that’s all from me. I’ll stop showing you. So that’s all for demo. And this shows how George and Camilla can work in parallel and create these beautiful applications and publish in the custom. Thank you, Varun. So I think what we just saw is how George, without requiring any AM expertise, can use the headless forms APIs to orchestrate and create digital enrollment experiences for multiple channels using a React app or any other front-end frameworks. So the beauty here is we are not just going to provide data capture experience. It’s the headless forms definition will also include provisions for dynamicity like rules, as Varun mentioned. So George has now created the experience, the enrollment experience. Aya is going to fill up that form, sign up for Weekend Club, and as well as some activities. Now it’s time to engage with Aya and send her some communications to the customer. So Vijay is now going to go over a demo where John can easily build these communications using APIs. Over to you, Vijay. Can you see my screen? Can you see my screen right? Yeah. OK. So let’s start with the communication API. Thanks, Varun. So the communication API follows the open API specification. And it currently has two types of authentication, just token-based and basic authentication. Protection, it is recommended to use token-based authentication. And there is a public document available to retrieve the process of token. And using it in the API. So let’s now see John, a form’s developer persona, can generate a statement like a welcome kit or a monthly statement using these APIs. In most of the use cases, in general, there are two use cases. So yes, when the statements are generated on demand, like sending in a welcome with whenever the user subscribes or maybe address change even. And another part is the batch mode is more of the statements generating in the high volume on a scheduled basis, say, generate monthly statements or weekly or yearly statements. So to you, batch mode, there is some pre-requesting. It is Azure Storage account. So customers need to provision Azure Storage account. And it’s expected the data is available in that storage account. And the final results will be, again, stored back to the same storage account. And the very high level flow of the batch will be the customer need to create a cloud configuration. And then they need to create a batch data source configuration and then upload the template, which was provided by the designer. Now let’s see this in action look like. So the synchronous APIs are very straightforward. You just need the data and just so the template can be an absolute URL or it can be a relay. The absolute will be in case of the HTTP URL. So you have already seen the statement. So this is more of a synchronous, very general statements on demand. And it takes on a request of data and template. Now let’s look at how batch works. So as I mentioned, that we need a storage account. And I have already provisioned an Azure Storage account and placed the customer details in this, our weekend customer details in this records folder. You can see there are two files. One is related to Aya and one is related to Jeff. And now let’s try to create a monthly statement for these records. So the first step, which I have mentioned, was to configure the cloud configuration. So this is the AM cloud configuration for Azure, where we have specified the account name and account. And the next comes the, maybe specify which folders to be used or which containers to be used. So in general, Azure Storage have multiple container. So for example, I have said batch demo container. In that, there is a records folder where you can find the data examples. And similarly, we can specify where the output need to be stored. So that’s, again, to the same container, but in the different folders name statements. And the final step before using the API is to upload the template. So I have already uploaded the statement.xtp into AM forms console. So we can use the batch APIs. So they are completely based on all. So we can directly use it from the Postman or cURL. I will be demonstrating using CLI. Mostly, this will be a part of AIO CLI plugin after the GAO of communication APIs. So let me start with the help. The batch are categorized into two sections. One is configurations, where you need to create a batch configuration, creating a configuration, reading, updating, and reviewing. And another is executions. So the execution is where you start the job and you track the job status. So I have already configured to use my AM setup. Let’s try to list all the jobs available in the setup. So I say config list. In terms of get API using the config path, and the command is list. You can see that already configuration exists. And there is config. So let’s dig into that and see what does actually configuration means. And the data source location, which we have previously seen, it is a full absolute part of the AM. And this is the interesting part, where we need to specify the output. So currently, we support both output formats. That is to generate a PDF or to generate a printed document. So printed documents are like Postgres, PCL. So in the case of print, we need to specify more details, like which kind of render type you want to use. So here I have specified HPE PCL, which is print control language. And finally, which we need to use for merging the data. So this is the configuration it looks like. Let’s create a configuration with this. And I just provide the DSM here. The batch is created successfully. Let’s list it out and see whether it is showing in the list. So we can see the weekend job now. Now let’s start a job. To start a job, we need to use the exhibition if we provide the job name. So command is start and say the weekend job, the name of the job. What it does is, so it starts a job in the background and provides us with the identifier through which we can see the status of the job status. Or we can simply say, let me all the executions which has been done. I say, let me all the execution. As you can see, there are a few more executions have occurred in this. And having such a state. And the last one is in processing with the weekend job. Now this is more of a very high level status that it is processing. But if we need more, what exactly does it is doing, then we can say, get me the status of particular job. And this is under execution. This will provide us more details. For example, in Azure storage, there are two records. And we have specified to generate two output types. One is PDF and print of type PCL. There are two work in progress as of now. So the both are both PDF and print. Yeah, I think it’s executed. So one, it’s stored in the statement, destination location. And if you can see here, there are two folders, one with name PDF and PCL. This is because we have to say to generate an output type like PDF and PCL. So if we go inside, then we can see a success folder. In case there are any issues in the data or template or any other issues, then it will be shown in your folder where it contains the more details of the failure. But since the job is success, everything is in success folder. As we can see, there are two PDFs generated. Let’s see the IF statement. How does the end PDF look like? So as we can see, the data has been given that the blueprint, like name, and the activities she has been included along with this table is coming as a part of data and remaining things like the thank you for being weekend member and some static content and some images like this one, logo of weekend, content coming from the template. So here’s the statement. And similarly, we have the statement. We also have the printed format for the PCL. That’s it from the demo. Back to you, Arun. Thank you, Vijay. So you just saw how George and John and Camilla as a team at Weken are able to orchestrate an end-to-end digital enrollment journey using APIs. So the key takeaway is with these two features and APIs, we unlock an API-first approach to orchestrating digital enrollment. We allow omnichannel delivery of forms using headless APIs and its headless representation. And then, of course, empower the front-end developer. They don’t have to know AM coding to build front-end apps that have digital experiences for enrollment. And then finally, we enable complete digital enrollment using communication APIs. So not just stop at the initial data capture and enrollment, but continue engaging with the customer using communication services and APIs. That’s it for this session. If you have any questions, please put them on the chat. So the recording for this session will be available in a couple of weeks. If you want to share it with the rest of your team, please do so. And thanks again for joining.