Communications (Output Service)

Transcript

Now let’s look at the communications use case. Output Service will be available soon on Cloud Service and addresses our customers’ communications use cases. Output Service can generate on demand communications, like welcome kits, as well as schedule batch communications, like bills and statements, et cetera. It’s a service-based approach to adoption*. And HTTP APIs will be available to invoke the Output Service. As mentioned, the communication use cases, there are two types. Synchronous low latency single record scenarios, like welcome kits. And asynchronous high throughput multiple records scenarios, like bills, monthly account statements and citizen benefits statements, et cetera. Now let’s take a look at a demo from unwrap on the output service. {Instructor 2} Hello. In this video, we will see AR forms to the Cloud Service communications APIs in action. There are two operations that are provided as HTTP API first is to merge data and template to generate a PDF output. The second is to merge data and template to generate a print output like postscript, PCL, and CPL. These output documents can be sent over email or print channel as desired head is my and forms as a Cloud Service cloud environment containing three different environments, dev stage and production on these environments. Communications APS have been enabled. In the postman UI I have important discography provided with the documentation to create the API definition. The base URL has been set to connect to my Cloud Service instance. Their two APAs generate a PDF document and generate a post-script document.

Suppose IR10 and end user wants to obtain her monthly statement. She clicks a link on the banks webpage automobile app to download the statement the application obtains the document template and the customer specific data from the backend data store invokes a communication API to most up together and create the monthly statement. Here is the document that has been created by the bank to capture the monthly statement. It contains a lot of fields, a particular layout, a certain branding and styling information.

Here is the customer specific data that has been fetched by the application from the packet. Now let’s provide this document template and the data within the API and see the document generation in action. So let’s select the data file and the template and invoke the API within seconds, the final gender document is provided IR10 to containing her monthly statement for viewing. Now suppose there is another scenario to generate purchase orders in bulk say on a monthly basis or weekly basis. So let’s invoke the other API.

Before that, let’s see the purchase order template. Here is a purchase order template designed using the AEM forms designer. It’s a single paged document template containing some reputable fields for the lot of data that will come within the part number description, quantity, unit price, and amount and then find in fact relations will be done.

In addition to the template, the data that is faced by the application from the backend data store is lodged. So it will result in a multi page document to be generated. Now let’s provide this document and the template to the API to generate a print document, let’s select the data file and the template.

And we have provided some of the print configuration parameters as options. If we invoke the APA within seconds, the document is returned to us. It says status 200. Okay. But the document is not a PDF file, so it cannot load, but we can save it to a different file. Say response one dot, yes and this is a postscript that we generated. So if you open it using distiller, it says, do you want to convert it? And a response, one dot PDF has been generated, which is a purchase order containing all the data that was fetched from the backend and the calculations have also been done. So here’s the final document that can be generated within batch. There are a number of documents, little use cases that can be solved within using these two APIs.

{Instructor 1} Now it’s time to take a look at how you can do a local setup. And also what does the developer experience look like? A local development environment Can be set up by installing the local cloud-ready Quick start that is available from the software distribution portal and then forms add on and also be downloaded from the same portal to install on top of the local cloud ready SDK, and it’ll enable all the forms capabilities. There’s a version of the forms add on available for Linux Mac and windows AEM project can be set up to manage the custom code. The Maven project architect 25 and above include support performance. Just like the Cloud Service overall cloud manager provides a CICD pipeline to bring in custom forms, applications, and custom forms code from the customer managers’ report custom code an AME release is merged into a unique tenant immutable image in cloud customers can then access these environments on the cloud manager and run non-production and production pipelines to deploy builds. The core team can be tested on them before we promoted to state in product. Now all settings like adaptive forms, cash size form, data model, SVP, client configurations, whitelisted URLs forms, et cetera, and part of on Cloud Service. Whereas customer adaptive form components, custom services like refill submit and client libraries for complex functions for the rule editor part of custom code and development.

Finally, we have the best practices analyzer tool that now includes support for AEM forms and can be used to estimate the effort required for migration to Cloud Service and also content migration tooling is available to auto transform the role editor code to the new visual code, that we have structured. Thank you. And that’s it for this session. - -