IT Process Automation

Expand all | Collapse all

Custom Operator for embedded links to IRF Forms in email notifications

  • 1.  Custom Operator for embedded links to IRF Forms in email notifications

    Posted 07-17-2012 10:22 PM
      |   view attached
    Hi,

    With PAM 4.0 SP1 came the possibility to dynamically create embedded links to IRF forms. Specifcally, the Assign User Task operator now has a TaskID operator variable which could be used to create the link. An example of how to use this is documented in the 4.0 SP1 Content Designer Reference on pg 380. Bascically, an IRF form is assigned and an email is simultaneously generated with the a direct link to the IRF Form. I took this idea and wrapped it into a custom operator since I knew it would be something that would be used over and over again. I have attached an export to this thread. Hopefully someone else will also benefit from it.

    To use it, you fill in all fields as usual except now in the body of the email message, you can use a special keyword of __FORM_URL__ which will automatially be replaced by a link to the assigned IRF Form. To access the values entered by the user on the IRF form, in the post execution code of the custom operator, you can reference the fields like this:

    Process.data_entered_by_user = Process[OpName].taskResult.form_field_name

    where taskResult = a valuemap containing the entire operator dataset from the original Assign User Task operator
    where form_field_name = the name of the form field on the IRF form that was assigned


    NOTE: Modifications to the process path from the custom operator will be needed before this works for your environement but other than that it should work fine.

    Attachment(s)

    zip
    IRF_Email.zip   32K 1 version


  • 2.  RE: Custom Operator for embedded links to IRF Forms in email notifications

    Posted 08-23-2012 11:14 AM
    Very nice!
    It all works well.
    Thank You very much.
    Brent


  • 3.  RE: Custom Operator for embedded links to IRF Forms in email notifications

    Posted 08-24-2012 11:19 AM
    Hi,

    I recently discovered a problem with this CO. In the data init code, you are unable to use:

    Form.field = Process.var
    Form.field2 = Process[OpName].var

    because Process and Process[OpName] get evaluated in the subprocess that the CO calls and not in the process using the CO. However, you can still use this version of the CO to pass in literal values to the Form. I already have a fix and will upload the new version soon. The new version also includes ability to send attachements and an email touchpoint field to use for referencing a system where the attachement file is located. I'm just waiting for CA to release a patch (expected soon) as the new CO requires it to work correctly.

    James


  • 4.  RE: Custom Operator for embedded links to IRF Forms in email notifications

    Posted 08-24-2012 03:04 PM
    Hey James,

    When using the Start Process operator (to call another PAM Process), you use Caller.<varname> to reference variables from the parent Process. This is true whether you're using Start Process directly or via a custom operator.

    However, I'm not sure that's what you want to do here. Normally when you design a custom operator, you want to hide the standard operator fields such as "Dataset Initialization Code". Can you help me understand why you want to expose or use those fields in your custom operator?

    Thanks,
    Tom


  • 5.  RE: Custom Operator for embedded links to IRF Forms in email notifications

    Posted 08-25-2012 01:49 PM
      |   view attached
    Hi Tom,

    I don't expose the Process initilization code field of the subprocess...

    My custom operator is a wrapper to an Assign User Task operator. Because of that, I need a way to allow a user to enter Form initilization code. To do this, I created a new field in my CO where the user can enter form init code which will be passed from my CO to the subprocess Assign User Task operator form init code.

    The problem is that when the form init code gets evaluated in the subprocess, all the special variables entered in the form init field of the CO ( Process, Process[OpName] ) refer to the subprocess.

    My solution was to copy all Process and Process[OpName] variables (from perspective of Process using CO) to the subprocess (in the CO pre-exec code) and then do a regular expression search/replace before evaluating the code. The other problem was with relative paths in Dataset expressions. The relative path gets evaluated from the perspective of the subprocess. The solution was to pass to the subprocess the base path of the Process using the CO (also in the CO pre-exec code) and again doing a regexp search/replace before the code gets evaluated in subprocess. The solution works well and I currently have it working. The only other thing that I can think of that will also fail is other constructs that use relative paths (will tackle those as I need them).

    I attached the new CO, but again, beware that it will require CA's next patch before all features work correctly.

    Attachment(s)

    zip
    Assign_IRF_Email_V2.zip   34K 1 version


  • 6.  RE: Custom Operator for embedded links to IRF Forms in email notifications

    Posted 10-03-2012 09:25 PM
      |   view attached
    Small fix in CO post exec code for better cleanup of copied variables...

    Attachment(s)

    zip
    Assign_IRF_EmailV3.zip   35K 1 version


  • 7.  RE: Custom Operator for embedded links to IRF Forms in email notifications

    Posted 05-31-2013 11:13 AM
    HI jdafoe .. this operator is great however I am still a bit beffudled on how to pass more than a single "variable" (string) to the form

    For instance if i use a single variable (note no semi colons)

    Form.var= Process.var .... then it works fine

    However if I try ....

    Form.var1 = Process.var1
    Form.var2 = Process.var2

    Then i get an error stating "enter a valid expression"

    I realize you had to do some "hacking" to get this issue to work however I was wondering what I am missing ...

    Thanks

    -David


  • 8.  RE: Custom Operator for embedded links to IRF Forms in email notifications

    Posted 06-03-2013 05:01 PM
    David,

    I can't tell if you are trying to use the custom operator as is or if you are trying to modify the underlying process. Where are you "Form.var1 = Process.var1"?

    Thanks,
    Tom


  • 9.  RE: Custom Operator for embedded links to IRF Forms in email notifications

    Posted 06-03-2013 05:25 PM
    Hi Tom .. thanks again for the response.

    All I am trying to do .. (imagining this would be needed "out of the box behavior) is pass more than a single string in the Form Data initialization code in the User Task portion of the operator.

    Form.urlToDisplayInIRF = Process.urlToDispay

    I would like to pass a couple more sections of information read only (however dynamic) text.

    As mentioned I am getting what amount to “syntax errors” when attempting.

    Thanks

    --David


  • 10.  RE: Custom Operator for embedded links to IRF Forms in email notifications

    Posted 06-03-2013 06:09 PM
    Hi David, I just tried this with 4.1 and didn't have any issues. What version of PAM are you running?


  • 11.  RE: Custom Operator for embedded links to IRF Forms in email notifications

    Posted 06-04-2013 04:44 AM
    Hi David,

    the same for me, i use this feature commonly and it always worked correctly.

    as Tom said, wich version are you using?

    Miguel


  • 12.  RE: Custom Operator for embedded links to IRF Forms in email notifications

    Posted 06-04-2013 01:47 PM
    Hi gents ... I am using 4.1

    I just tried again .. only this time I used comma separated as below ..

    Form.manFormURLWhitelistReq = Process.pStheURLforWhitelist,
    Form.manFormBusinessJustifictionTF = Process.pStheURLforWhitelist

    When I closed the form, the error "enter a valid expression" did not appear.

    I ran a test and it worked! lol

    eghmmm is there somewhere in the accompanying information that I missed that comma separated is the correct syntax or did I somehow have a happy accident lol

    I have to do futher tests however ....

    Thanks

    --David