none
Binding an RCDC textbox to a workflowdata item RRS feed

  • Question

  • Hi,

    Is it possible to present a textbox in an RCDC that passes the value entered to a workflow process.  Perhaps a little background, I need to generate an email that presents HR with information about a new user, but the information is related to their post, and not their identity, so I do not want it held on the user record.  I could create dummy user attributes and initialise them at the end of the worflow, but that would be a workaround.  I would like to bind the textbox to a workflowdata item ( eg [//WorkflowData/WOrksharingPost] ), and reference this from within an email template.  Is this possible?.  If so, some sample xml would be useful.  I have played around with my RCDC, and while it's not failing, it's not passing the value to the workflow.

    Tuesday, September 11, 2012 8:58 AM

All replies

  • I don't see any way for that to be done ;). Besides that this is not possible - given workflow data exists only in a context of given workflow instance - this instance might be already finished when you display RCDC, there might be also as well multiple instances of that workflow for a given identity. Too much complication :).

    Tuesday, September 11, 2012 7:03 PM
  • HI Tomasz, thanks for your response.  Just for my own information, the workflow I'm passing to is a Create User instance, and should not start until the request is submitted, and the item being passed is called at the start of the workflow, so I don't see how the instance could have finished before the RCDC renders.  One worrying point, we are using building block workflows (that originated from MCS Poland!!) in several places in our solution, are you saying that there can be cross  contamination of data within workflow data if another workflow is initiated for the same identity?.  This could have dire consequences for our entire solution.
    Wednesday, September 12, 2012 9:19 AM
  • Hi

    (...) the workflow I'm passing to is a Create User instance, and should not start until the request is submitted, and the item being passed is called at the start of the workflow, so I don't see how the instance could have finished before the RCDC renders. (...)

    OK - so here is scenario:

    - You are using Portal to submit a request to create a user. When you will hit "Submit" you are placing a request. 

    - Your request is triggering a workflow, even few of them. These are running in parallel asynchronously. This workflow can do some actions, for example generate some WorkflowData attribute, and then ends. 

    - you are opening RCDC for this user, workflow you have triggered with previous request might not even start (depends on the number of requests, authorization processes, FIM Service box load), be in a running stage ( you don't know at which stage) or be completed (finished and not running anymore). So where should your RCDC bind and how to ensure that this data is available.

     Now imagine that you have two or three requests which are for example changing the first name of a user and changing account name. Submitted in close time and all of them has triggered a workflow instance to update some attribute. Which instance should your RCDC pick? In multiple server environments in addition to this you have workflow running at one of the boxes, you don't know which - but this could be hidden by FIM Service interface.

    Of course this is all theoretical because this isn't possible in FIM at this moment :).  

    (...) One worrying point, we are using building block workflows (that originated from MCS Poland!!) in several places in our solution, are you saying that there can be cross  contamination of data within workflow data if another workflow is initiated for the same identity?.  (...)

    Good to hear that you are using some good stuff from my former MCS team :). And you don't have to be worried - no, instances of workflow are separate and workflowdata are separate by instance of a workflow.  Sorry if you've got other impression from what I wrote. 

    Wednesday, September 12, 2012 12:26 PM