cancel
Showing results for 
Search instead for 
Did you mean: 

BpmnParse throws Errors after 5.11 upgrade

jcavezian
Champ in-the-making
Champ in-the-making
Hello everybody,

I have decided to upgrade Activiti-Engine from 5.10 to 5.11 in my JEE application.
Librairies and database schema are up-to-date now.

After running around my application, I add some errors such as
Exclusive Gateway 'exclusivegateway3' has outgoing sequence flow 'XXX' which is the default flow but has a condition too. | diagrams/XXX.bpmn20.xml | line 0 | column 0
Fine… I corrected definitions, re-deployed and now everything works fine with new executions.
But with existing running executions in the database before upgrade, I still have this kind of errors. Indeed, older running executions are based on older definitions, which obviously still have the problem.

Thoses errors are raised by the method
com.activiti.engine.impl.parser.BpmnParser.validateExclusiveGateway(ActivityImpl activity)
, which seems to be new in 5.11.

Is there anyway I can make those executions work in 5.11 engine ?

Thank you all for your help.

Best Regards, Jerome
4 REPLIES 4

frederikherema1
Star Contributor
Star Contributor
I'm afraid there is no easy way to fix this, other than updating the XML's in the ACT_RE_BYTEARRAY table, for the processes that cause the error to be thrown. There is no way of disabling that check/error…

jcavezian
Champ in-the-making
Champ in-the-making
I was kind of expecting this… But I wonder how you could let this append ?!
You could have provided a patch with this !

Anyway, here is a snippet of my own patch :


/**
     * Remove 'default' attribute on 'exclusiveGateway' nodes.
     * @param bytes xml binary data
     * @return correct binary data
     * @throws SAXException exception
     * @throws IOException exception
     * @throws ParserConfigurationException exception
     */
    private byte[] removeExclusiveGatewaysDefaultAttribute(byte[] bytes) throws SAXException, IOException, ParserConfigurationException {
        ByteArrayInputStream inputStream = new ByteArrayInputStream(bytes);
        Reader reader = new InputStreamReader(inputStream, "UTF-8");
        InputSource is = new InputSource(reader);
        is.setEncoding("UTF-8");
       
        DocumentBuilder db = DocumentBuilderFactory.newInstance().newDocumentBuilder();
        Document document = db.parse(is);
       
        NodeList exclusiveGateways = document.getElementsByTagName("exclusiveGateway");
        for (int i = 0; i < exclusiveGateways.getLength(); i++) {
            Node node = exclusiveGateways.item(i);
            if (node.getAttributes().getNamedItem("default") != null) {
                node.getAttributes().removeNamedItem("default");
            }
        }
        return getStringFromDoc(document).getBytes("UTF-8");
    }

    /**
     * Serialize a Document to String.
     * @param doc doc to serialize
     * @return serialized doc
     * @throws IOException exception
     */
    private String getStringFromDoc(org.w3c.dom.Document doc) throws IOException    {
        StringWriter sw = new StringWriter();
        OutputFormat format = new OutputFormat(doc);
        format.setIndenting(true);

        XMLSerializer serializer = new XMLSerializer(sw, format);

        serializer.serialize(doc);
        return sw.getBuffer().toString();
    }

The idea is to iterate on each deployment from act_re_deployment table and retrieve records from act_ge_bytearray table, with the foreign key deployment_id_.
Only process records matching generated_ = false and name_ like '%.xml'The orm-dao layer is really easy to implement, that's why I don't provide it here…
Regards, Jerome

rkroll
Champ in-the-making
Champ in-the-making
I would recommend updating the release notes to let users know that this is a breaking change.  We upgraded only to find that our previously deployed processes now cause parse exceptions - we need to either downgrade or delete all previous deployments, neither of which is a great choice.  Based on jcavezian's patch, it seems like there is a potential way to update existing processes and avoiding the problem entirely.  I am amazed more users are not experiencing this issue!

trademak
Star Contributor
Star Contributor
Hi,

I agree of course that the issue being raised is not handled very elegantly by Activiti.
However, having a default flow with a condition is not a good implementation.
But I think there's a good solution to this issue available in Activiti (somewhat hidden).
You can deploy a new version of the process definition that corrects the issue and then use the SetProcessDefinitionVersionCmd to move the existing process instances to the new process definition.
Again, we should prevent introducing new parsing issues as well.

Best regards,