Enhancing Fluid Forms with PeopleCode Event Mapping

Fluid Forms and Approval Builder is a handy utility that provides an alternative to paper based processes in a organization. It’s key features are the out-of-the-box integration with,

  1. File Attachments
  2. Approval Workflow Engine
  3. Component Interface Mapping

It is ideally suitable for building simple forms, collecting file attachments from users, invoking workflow approval process involving multiple users and finally updating a transaction component using component interface.

However a common feedback among customers is that this utility is too simple and not effective to build user friendly forms for real-world use-cases. Key limitations of this utility are,

  • Inability to default or load contextual data to the form
  • Inability to validate data entered by user
  • Lack of support for multiple levels of data (table structures)

While this utility is not intended to build complex pages like application designer, basic features like field defaults and validations are essential to build user-friendly forms.

Thanks to the ever so powerful PeopleCode Event Mapping feature. We can now effectively introduce custom business rules and validations to the forms built using Forms and Approval builder.

 

FluidForms

I have illustrated this capability using a simple form created for employees to claim expenses.

  • A fluid form is created using Forms and Approval builder, making use of the delivered attachment and workflow approval capability
  • PeopleCode Event Mapping Framework is used to
    • Pre-Populate form  with employee related information
    • Validate data entered by user when the form is saved, allowing the user to resolve any validation error

Designing and deploying a form using Forms and Approval builder is entirely an online configuration activity, using PeopleCode event mapping framework to build and add business rules to the forms is a technical activity.

Explained below is the summary of steps to build a form as shown in the video.

  • Use Form Designer utility to build and deploy a fluid form, making use of the full set of features like file attachments, workflow approvals, security

FluidForms1

  • Deployed form can be added to a Fluid Homepage
    • Optionally you can set a image for the tile
    • When the form is accessed, initial component that is loaded – EOFM_CONTAINER_FL. This component basically acts as an index listing the forms already created and allows user to create a new form

FluidForms6

  • When user clicks to fill a new form, the form layout page opens, notice the Fluid Component for this page is – EOFM_FORM_FL. This is the component to which the Peoplecode needs to be mapped.

FluidForms7

  • Create an application package and class that contains the Peoplecode to execute your business rules. Record/Fields associated with the Form data elements can be figured out by reviewing the structure of the component – EOFM_FORM_FL

FluidForms3

  • Register the Application Package/Class Peoplecode as a service under,

PeopleTools>Portal>Related Content Service>Define Related Content Service

FluidForms4

  • Associate this new service to the target forms component under,

PeopleTools>Portal>Related Content Service>Manage Related Content Service

Note: Component – EOFM_FORM_FL as delivered is not available on the portal registry, so this has to be first registered in the portal, so that related events can be mapped.

FluidForms5

  • Test the functionality to suit your requirements

Note:

Peoplecode event mapping framework in PeopleTools 8.55 has capability to inject custom Peoplecode into component and component record field level events. This functionality is further enhanced in PeopleTools 8.56 providing more Peoplecode events such as page activate etc.

 

 

Advertisements

4 thoughts on “Enhancing Fluid Forms with PeopleCode Event Mapping

  1. Hi Logesh,

    Thank you for the explanation. We have a similar requirement and PS Forms were ruled out as they cannot handle defaults and validation logic. I am gonna give this a try now. We are on PT 8.55 and I hope it works as described in you article. Thank you!

    Vimal

    Like

  2. Pingback: #89 – Gotchas

  3. Hi Nick,

    Very valid question. In the custom application class, we can add logic to distinguish the form. Record Field – PS_FORM.FORM_TYPE is available on the form and carries the form template id that the user is currently accessing E.g. Expense, Supplier etc.
    So custom logic to default fields etc, can check the Form Type and execute code specific to certain forms.

    Like

  4. Hi Logesh,
    Thanks for the informative article – adding event driven logic to the forms makes them far more usable and powerful.

    Just a follow on question – if we are adding the PeopleCode event to the content reference, how is it able to distinguish between forms? i.e. If we have a Expense claim form and a New Supplier form, and want to have different logic to add defaults to them?

    Thanks,
    Nicholas Rule

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s