topic Re: BpmnParse throws Errors after 5.11 upgrade in Alfresco Archive

BpmnParse throws Errors after 5.11 upgrade

jcavezian — Tue, 15 Jan 2013 10:17:19 GMT

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 defau

Re: BpmnParse throws Errors after 5.11 upgrade

frederikherema1 — Tue, 15 Jan 2013 10:57:20 GMT

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…

Re: BpmnParse throws Errors after 5.11 upgrade

jcavezian — Wed, 30 Jan 2013 14:56:26 GMT

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

Re: BpmnParse throws Errors after 5.11 upgrade

rkroll — Mon, 25 Mar 2013 21:23:14 GMT

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!

Re: BpmnParse throws Errors after 5.11 upgrade

trademak — Tue, 26 Mar 2013 13:58:10 GMT

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,