#2 Submission after workflow import fails


2 URCs: Both client versions: 6.4.3, both Windows 7
The workflow contains 2 loops, each one with one job. The loops iterate over files from a storage.
The workflow export seams to be ok, no error messages in the client. An import of the workflow into the second URC leads to error messages during the submission process.
The first time we submit the workflow the error message was:
at de.fzj.unicore.rcp.logmonitor.LogActivator$3.run(LogActivator.java:268)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

So we did an export of the same workflow again and an import into the second URC.
The new error message is:
java.lang.Exception: Cannot submit workflow to workflow engine!
at org.chemomentum.rcp.wfeditor.submission.C9MSubmitter.submit(C9MSubmitter.java:429)
at de.fzj.unicore.rcp.wfeditor.model.commands.SubmitWorkflowCommand$SubmissionRunnable.run(SubmitWorkflowCommand.java:165)
at de.fzj.unicore.rcp.wfeditor.ui.WFSubmissionWizard$2.run(WFSubmissionWizard.java:197)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: org.codehaus.xfire.fault.XFireFault: Could not submit workflow. Workflow contains errors.
1: For-each loop 'ForEachActivity2' does not define an iterator.
2: For-each loop 'ForEachActivity1' does not define an iterator.
at org.codehaus.xfire.fault.Soap11FaultSerializer.readMessage(Soap11FaultSerializer.java:31)
at org.codehaus.xfire.fault.SoapFaultSerializer.readMessage(SoapFaultSerializer.java:28)
at org.codehaus.xfire.soap.handler.ReadHeadersHandler.checkForFault(ReadHeadersHandler.java:111)
at org.codehaus.xfire.soap.handler.ReadHeadersHandler.invoke(ReadHeadersHandler.java:67)
at org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131)
at org.codehaus.xfire.client.Client.onReceive(Client.java:406)
at org.codehaus.xfire.transport.http.HttpChannel.sendViaClient(HttpChannel.java:139)
at org.codehaus.xfire.transport.http.HttpChannel.send(HttpChannel.java:48)
at org.codehaus.xfire.handler.OutMessageSender.invoke(OutMessageSender.java:26)
at org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131)
at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:79)
at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:114)
at org.codehaus.xfire.client.Client.invoke(Client.java:336)
at eu.unicore.security.xfireutil.client.ReliableProxy.handleRequest(ReliableProxy.java:122)
at eu.unicore.security.xfireutil.client.ReliableProxy.doInvoke(ReliableProxy.java:102)
at eu.unicore.security.xfireutil.client.ReliableProxy.invoke(ReliableProxy.java:69)
at $Proxy21.submit(Unknown Source)
at org.chemomentum.common.impl.workflow.WorkflowManagementClient.submitWorkflow(WorkflowManagementClient.java:52)
at org.chemomentum.rcp.wfeditor.submission.C9MSubmitter.submit(C9MSubmitter.java:391)
... 3 more

We saw that the problem for the second error was the missing file declaration in the preferences of the for loop.
Adding them again, everything works. Maybe there is something wrong with the workflow export, some loop properties get lost.


  • Sandra Bergmann

    Sandra Bergmann - 2012-08-10
    • summary: Workflow import fails --> Submission after workflow import fails
  • Bernd Schuller

    Bernd Schuller - 2012-08-22
    • priority: 6 --> 5
    • assigned_to: nobody --> bdemuth
  • Bjoern Hagemeier

    • Affected Versions: --> 6.4, 6.5, 6.6
  • Bernd Schuller

    Bernd Schuller - 2013-12-13
    • labels: Clients --> Clients, URC
    • Fixed in: -->
    • Milestone: UNICORE6.4 --> UNICORE7.0
  • Bernd Schuller

    Bernd Schuller - 2014-01-08
    • assigned_to: Bastian Demuth --> Bernd Schuller
  • Bjoern Hagemeier

    Ticket moved from /p/unicore/bugs/573/

    Can't be converted:

    • _fixed_in:
    • _affected_versions: 6.4, 6.5, 6.6
    • _priority: 5
  • Bjoern Hagemeier

    • Type: --> Bug
    • Milestone: UNICORE7.0 --> 7.1.0
  • Bjoern Hagemeier

    • Milestone: 7.1.0 --> Backlog
  • Bjoern Hagemeier

    • Priority: --> 3
  • Bjoern Hagemeier

    • status: open --> closed
  • Bjoern Hagemeier

    I cannot verify this behavior anymore in 7.2.0. As this is a rather old but, I will close it and consider it fixed and working.


Log in to post a comment.