Topic
  • 4 replies
  • Latest Post - ‏2019-08-06T09:30:08Z by frisalde
frisalde
frisalde
113 Posts

Pinned topic Set the Requestee in a customized account operation workflow

‏2019-08-02T10:34:18Z | account; isim; requestee workflow;

We are a bit confused about how workflows are working.

 

We have realized that once a customization is done in an Account operation workflow, it is needed to set the Requestee by means of process.setRequesteeData() function. If not so, the Requestee is not filled as it can be seen in the attached screenshot.

 

We think that our customizations are not involved in this behaviour due to it is fixed by means of including the process.setRequesteeData() function at the Start node of our workflow, ie, as the first operation done. If the rest of the customization would be the responsible for it is not working, the Requestee who has been set at the Start node should be overwritten in a later stage.

 

Does it make sense?

Attachments

Updated on 2019-08-02T10:35:32Z at 2019-08-02T10:35:32Z by frisalde
  • franzw
    franzw
    515 Posts

    Re: Set the Requestee in a customized account operation workflow

    ‏2019-08-02T11:21:50Z  

    Unless I misunderstand your question this is not correct.

    Normally the requestee data should be included in custom operations unless you set it up explicitly not to do so.

    How is the operation (workflow) called - and how it is defined ?

    Regards

    Franz Wolfhagen

  • frisalde
    frisalde
    113 Posts

    Re: Set the Requestee in a customized account operation workflow

    ‏2019-08-05T11:54:12Z  
    • franzw
    • ‏2019-08-02T11:21:50Z

    Unless I misunderstand your question this is not correct.

    Normally the requestee data should be included in custom operations unless you set it up explicitly not to do so.

    How is the operation (workflow) called - and how it is defined ?

    Regards

    Franz Wolfhagen

    Hi Franzw,

    find enclosed the ChangePassword workflow where this odd behaviour happens.

     

    I have removed the whole of our customisations done and now it looks like the out-of-the-box workflow (although from the ISIM point of view, it is Used Defined).

     

     

    Attachments

    Updated on 2019-08-05T11:54:55Z at 2019-08-05T11:54:55Z by frisalde
  • franzw
    franzw
    515 Posts

    Re: Set the Requestee in a customized account operation workflow

    ‏2019-08-05T12:15:52Z  
    • frisalde
    • ‏2019-08-05T11:54:12Z

    Hi Franzw,

    find enclosed the ChangePassword workflow where this odd behaviour happens.

     

    I have removed the whole of our customisations done and now it looks like the out-of-the-box workflow (although from the ISIM point of view, it is Used Defined).

     

     

    Deleting your was not total.

    The Account ChangePassword operation original is operation 00...0025,ou=operations,ou=itim,<your tenant>  (if you hav changed that - it is the EntityType Account Change Password.

    When I compare your operations xml to the default on there is couple of significant derivations.

    You are having only 2 input parameters - the default has 3 - the missing one is the transactionId.

    You have scripts on the transitions - the default has nothing. Especially this one is probably doing harm :

     

          <REGULAR FROM="CHANGEPASSWORD" TO="END">
            <SCRIPT><![CDATA[activity.resultSummary!=activity.SUCCESS]]></SCRIPT>
          </REGULAR>

    This basically means that the workflow never reaches end unless the password change fails....

    The way to reset an Entity workflow to its EntityType is to delete it - the way ISIM finds what workflow to process is basically starting to see if there is match on both profile and name (Entity match) - if not it searches for an EntityType workflow....

    HTH

    Regards

    Franz Wolfhagen

  • frisalde
    frisalde
    113 Posts

    Re: Set the Requestee in a customized account operation workflow

    ‏2019-08-06T09:30:08Z  
    • franzw
    • ‏2019-08-05T12:15:52Z

    Deleting your was not total.

    The Account ChangePassword operation original is operation 00...0025,ou=operations,ou=itim,<your tenant>  (if you hav changed that - it is the EntityType Account Change Password.

    When I compare your operations xml to the default on there is couple of significant derivations.

    You are having only 2 input parameters - the default has 3 - the missing one is the transactionId.

    You have scripts on the transitions - the default has nothing. Especially this one is probably doing harm :

     

          <REGULAR FROM="CHANGEPASSWORD" TO="END">
            <SCRIPT><![CDATA[activity.resultSummary!=activity.SUCCESS]]></SCRIPT>
          </REGULAR>

    This basically means that the workflow never reaches end unless the password change fails....

    The way to reset an Entity workflow to its EntityType is to delete it - the way ISIM finds what workflow to process is basically starting to see if there is match on both profile and name (Entity match) - if not it searches for an EntityType workflow....

    HTH

    Regards

    Franz Wolfhagen

    Thanks for your remarks.

     

    I totally agree. Really, I didn't want to delete the custom changepassword workflow to show you how, a very simple workflow, which looks like as the default one, is not including the Requestee data (the transition condition was forgotten to be removed). So, same result has been got by removing the wrong transition condition. (see 2019_08_06_11_22_11_Clipboard.jpg attachment)Btw, Despite the wrong transition the workflow was ending (I think) due to the services profiles are defined as LOCAL in our TEST environment.

     

    Focusing in the target of the issue, the conclusion is that, as I suspected, it is not needed to set the Requestee, at least it is wished to change the default one. is it?

     

    On the other hands, I'll open an PMR due to (I don't remember when) during any ISIM upgraded the Account default workflows were overwriten by the previosly customization done at Account level. Thus, ISIM think that the default ones are the customized ones, so we are not able to come back to some out-of-the box workflows. For instance, the 000…025 is a customized operations.

     

    Moreover, our 000…025 operation has just 2 inputs parameters. Maybe this the reason of our odd behavoir.

     

    <PARAMETERS>         <IN_PARAMETERS EXTENDED_ATTRIBUTE="Entity" PARAM_ID="Entity"             RELEVANT_DATA_ID="Entity" TYPE="Account"/>         <IN_PARAMETERS EXTENDED_ATTRIBUTE="notifyFlag"             PARAM_ID="notifyFlag" RELEVANT_DATA_ID="notifyFlag" TYPE="String"/>     </PARAMETERS>

     

    Regards

    Felipe Risalde