Monday, April 21, 2014

The items that make workflow in H2O possible are Form postings, control visibility based on DotNetNuke Roles and/or based on the current step in the process, the ability to query your database using dynamic values, direct inserts into database tables with URL Redirects, H2O Scripting and the H2O Logic control.  At the time this was written, I was working on an H2O solution ( click here - also listed to the left) that involves multiple steps and covers most of the core functionality of work flow in H2O, so I will use this as an example.

H2O doesn't restrict you to limited boundaries like other modules with work flow capabilities.  H2O allows you to create your solution using the controls and functions of your choice in an ad-hoc fashion.   This gives you complete freedom to build your solution to fit your needs by combining the controls and functions of your choice in H2O.  You could even take your workflow outside the boundaries of H2O by redirecting your work-flow to another module that accepts Session and QueryString postings.  For example,Portal SignUp is a DotNetNuke module byOnyakTech that allows people to create their own portals on your web site with the option of paying for hosting services through PayPal.  You could eliminate the entire interf ace of Portal SignUp and replace it with your own custom H2O Forms interface with a final submission to the Portal SignUp module.  The module will then create the portal and then redirect the user to their new portal or back to your H2O Forms with status messages in Session variables. You could also create your own initial interface forSigmaPro with the final submission posting a new request to SigmaPro by connecting to the SigmaPro Web Service.  The possibilities are endless.  To demonstrate this, I'll walk through a few implementations that could be used to create the example solution. 

 

The most basic need in this solution is the ability to carry information from one form to the next with the option of having points where the process may be on hold until approved for the next step.  To carry out these transitions, you can use one ore more of the following:

  • H2O Link Control: This control is vital since we will not want to store data at every stage of the process and we'll need a way to move on to the next step.  You can use this control on a form that is not associated with a project.  This control also allows you to carry values into the next form by forcing all values entered into the current form to be posted as QueryString parameters. To do this, you can combine two functions.  The Execute H2O Script function and the Post Results To URL(Link) function.  Click here for a screen shot of what this looks like.  You could also use the Execute H2O Script function with the Post Results to Form(Link) function.  The Execute H2O Script function will execute all H2O Script enabled controls on your form allowing you to prevent the form transition if specific conditions are not met.  If you don't need to worry about this, then you can use the Post Results function by itself.
  • H2O Scripting Functions: Post Results to URL and Session Post.  These can be used with forms that are associated with a Project to store the current forms data before moving on to the next step.  To quickly use these functions, select Post Results To URL or Session Post from the Functions drop down while editing a Label or Hidden Field control. 

The Connection:

In order to move data from one form to the next, you need to have controls that are the same name on each form.   If you have information that you don't want displayed or are carrying information from a few forms back, you should store this information into the Hidden Field control.   This is all you need to do, H2O h andles the rest.   For example, if FormA has a control named FirstName and FormB has a control named FirstName, when the transfer is executed using one of the methods listed above (Post Results To Form, URL, etc) H2O will copy the value entered into FormA over to FormB.

Obtain Dynamic Data Based on User Selection

In the example in the above diagram, the user is requested to select the Inspection Type.  This selection controls the inspector they can choose to handle the job in another form.  The list of Inspection Types may change over time so this information may be stored in a table in the database.  To build this list, you would use a External List control and type your SQL Statement into the H2O Script Control textbox.  A few more steps into the solution and we'll need to use External List control again for the user to select from a list of available inspectors that can handle the job.  To build this list, we'll need the Inspection Type the user selected to build a dynamic SQL Statement.

QueryString parameters, Session variables and the available H2O SQL Tags can be used to generate dynamic SQL Statements to populate control values in your form.

  • QueryString Parameters:  [QRY-PARAMETER]  Ex: Select InspectorName, InspectorID from Inspectors Where InspectionType = [QRY-InspectionType].  InspectionType is the name of the control in this example, which is also a QueryString parameter.
  • Session Variables:  [SSN-PARAMETER]  Ex: Select InspectorName, InspectorID from Inspectors Where InspectionType = [SSN-InspectionType]  InspectionType is the name of the control in this example, which is also a session variable.
  • H2O SQL Tags: For this example, we won't need to use these but they are listed below for your reference.   They are used the same as the QueryString and Session examples.  Ex: Select UserName from Users Where UserID = [USR-USERID].  These tags are replaced with current information related to the tag.  In this example, the tag is replaced with the current users User ID.

The following tags are available for the External List and Data Grid controls for use in SQL Statements.

  • [USR-USERID] Return the current users User ID
  • [USR-LASTNAME] Returns the current users Last Name
  • [USR-USERNAME] Returns the current users User name
  • [USR-FULLNAME] Returns the current users Full Name
  • [USR-FIRSTNAME] Returns the current users First Name
  • [USR-AFFILIATEID] Returns the current users Affiliate ID
  • [ATB-URL] Returns the Active Tabs Url
  • [ATB-TITLE] Returns the Active Tabs Title
  • [CPT-EXPDATE] Returns the portals Expiry Date
  • [CPT-ADMID] Returns the portals Administrator Id
  • [CPT-ADMROLEID] Returns the portals Administrator Role Id
  • [CPT-ADMROLENAME] Returns the portals Administrator Role Name
  • [CPT-HOMEDIR] Returns the portals Home Directory
  • [CPT-HOMETABID] Returns the portals Home Tab Id
  • CPT-HOSTSPACE] Returns the portals Host Space
  • [CPT-LOGTABID] Returns the portals Login Tab Id
  • [CPT-PORTALALIAS] Returns the portals Portal Alias
  • [CPT-PORTALID] Returns the portals Portal Id
  • [CPT-PORTALNAME] Returns the portals Portal Name
  • [CPT-REGROLEID] Returns the portals Registered Role Id
  • [CPT-USRTABID] Returns the portals User Tab Id

PopUps or Direct?

You can alter between the use of H2O PopUp Windows and direct forms in your solution depending on your needs.    For example, in Sub-Form 5 of the diagram we may want to display a list of Inspectors in a normal H2O Form (Direct) with a Link control that opens a new form into a popup displaying information about the selected inspector. This allows additional sub-form processing while leaving the parent form open for future saves.   If the popup Form is associated with a table in your database you could include a Link control in tha t form that uses a Post To URL H2O Script function to the URL provided in the Form Details - (Click here for a screen shot of a form associated with a table).  In this situation, you may want to provide a Redirect URL (entered into the Form Details screen) to return the user to the work-flow after this information is saved from the PopUp.\

How to handle steps that require approvals:

To handle approvals, you will need to secure controls using the Secure Roles option for the control in the Forms Control Editor . The list of DotNetNuke Roles in your portal is displayed when you click on Security Roles.  Check the roles you want this control to be visible to and click the Update Control Info link.  When the form is rendered, the current user will only see this control if they belong to one of the DNN Roles you checked here.

An example: Add a Checkbox control to your form that is secured to the Administrators Role and name the control "Approved".  Then add a Link control to the form that will post to the next form in the process.  Use an H2O Logic control to hide the Link control until the Approved Checkbox is checked.  You could also use an Email Response control to email the user of the updated status if they are not registered on your web site.

 

Copyright 2012 by OnyakTech Privacy StatementTerms Of Use