Announcement Announcement Module
Collapse
No announcement yet.
URL ignored when resuming flow execution Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • URL ignored when resuming flow execution

    I'm not sure if the behaviour I'm seeing is expected or if something isn't quite right with our configuration.

    If I hit a URL /forgottenUsername, the expected flow is executed and the correct view rendered. The resultant URL is /forgottenUsername?execution=e1s1

    If I manually change the URL to /main?execution=e1s1, the flow that maps to /main is not invoked. In fact, I can change the URL to any value e.g /blah?execution=e1s1 and the forgottenUsername flow is always resumed. I would have expected an exception of some sort to be thrown.

    It appears that only the execution parameter is considered when resuming flow execution. Is that correct?

  • #2
    It's probably something with your configuration.

    You are right, by default, when a flow execution key is set in the parameters and the execution is not found a new flow execution is launched.

    But what you are explaining about blah?execution=e1s1 resuming a different flow sounds like a problem in your config.

    What if you enter the urls without the execution parameters? what happens when you go to /main or /blah?

    Comment


    • #3
      I've figured out the issue with /blah and it's unrelated - was a simple 404 mapping in web.xml that was responsible.

      If I omit the execution parameter the flow isn't resumed which is what I'd expect. But, if I change the URI (to one that is valid) and leave the execution parameter intact, the flow that maps to the original URI is resumed.

      From looking at the source, webflow retrieves the flow by execution key and not flow id when it resumes execution which I guess explains it.

      Comment


      • #4
        Yes, you are right. I didn't think so but you are.

        If it's not a bug at least it's unexpected behavior.

        Comment


        • #5
          Work around

          Hi guys,

          I raised similar issue last year and I received a possible work around.

          Comment


          • #6
            Thanks Salvoj, that's exactly the same workaround that I ended up implementing. Seems a bit strange to have to do that but it works fine.

            Comment


            • #7
              It would be nice if you could open a jira for this and attach the code with the workaround to see if we can get this fixed for everybody.

              Comment

              Working...
              X