[xml] Allow to check Salesforce XML Metadata using XPath rules

[rsoesemann]

I want to use the XML version of PMD to find issues in Salesforce.com metadata which is often XML formatted. The problem is those files never end as ".xml" but as ".flow" or ".meta-xml".

How would I need to run PMD to make that work? Or is this currently unsupported as this open issue might support #1540?

[aidan-harding]

I'm trying to do this to be able to add to PMD's Salesforce analysis capabilities. In particular, Salesforce Process Builder processes are stored in xml files ending .flow.

It's nice and easy to write some XPath rules, but PMD returned a parsing error when I tried to run them on a .flow file. I tried:

pmd -R ~/my_xml_rules.xml -l xml -f text -d src/flows/MyFlow.flow

Which resulted in:

PMDException: Error while parsing src/flows/MyFlow.flow

If I copy the flow to end in .xml, and run:

pmd -R ~/my_xml_rules.xml -l xml -f text -d src/flows/MyFlow.xml

Then PMD runs successfully and finds the problems I expected it to in the file.

Currently, I use PMD in Gearset to monitor code quality in my Salesforce production system. Ultimately, I want to be able to use PMD on XML files with Gearset to monitor declarative tools like Process Builder and hold them to standards the same way as we do for Apex.

[rsoesemann]

@aidan-harding reading through the history of the related issues I thing changing the PMD CLI would be to hard and inflexible. I'd go for an additional "extensions" attribute in the ruleset. Check my last comment in #1540.

[aidan-harding]

Thanks for following up!

I wonder if accepting files from stdin might be another route? Or would that run into the same inflexibility within the CLI?

[rsoesemann]

Not sure but my goal would be to make this a small and non-invasive extension that could be:

1. Implemented and releases withing PMD 7
2. Easily integrated with Gearset, Copado, VSCode, Illuminated Cloud and Codacy

[rsoesemann]

@gwilymatgearset just in case you want to work on this, I assigned it to you, me and @aidan-harding who had some interest and ideas into that. It would be great if we could collab a bit on that here.

[ankushsomani09]

My few use case are:

• Don't allow Users as recipients in workflow email alert.
• Don't allow Permission set which only have 1 or 2 field permissions. ( kind of empty permission set)
• Detect Duplicate Label field on object and give warning.
• Use Profile for Page Layout only, restrict not to put Field and object permission and etc.

[rsoesemann]

@ankushsomani09 can you please be a bit more specific per use case e.g. describing this:

Use Case: Don't allow Users as recipients in workflow email alert.

• Why needed (including links to references): ....
• Metadata file types to run this on:
• XPath Implementation draft: /xml/receipient

[rsoesemann]

@oowekyala I saw your recently deprecated Abstract XML rules classes like "AbstractWsdlRule". If we want to add Java-based rules for Salesforce XML dialects is there a new way to go?

Please advise me and @aidan-harding

[oowekyala]

For reference, the parse exception is because we fall back on the java parser because we don't recognize the extension.

@oowekyala I saw your recently deprecated Abstract XML rules classes like "AbstractWsdlRule". If we want to add Java-based rules for Salesforce XML dialects is there a new way to go?

I believe if there really is a push to support java XML rules then they should directly use the underlying DOM nodes. I think that should still be supported.

However I think while XPath suffices, it should be preferred. Note that the XPath API can be extended with language-specific functions. They're implemented in java, so are very powerful, but XPath rules can use them in an idiomatic way. This is how pmd-java has pmd-java:typeIs("java.lang.String") for instance. I think this is the best of both worlds.

FWIW I don't see why #2133 (comment) couldn't be implemented with just XPath rules

[rsoesemann]

To answer your "I don't see why #2133 (comment) couldn't be implemented with just XPath rules" :

XML XPath rules would work but only when the file extension is .xml. In Salesforce whatsoever the extension is different. Object XML files end with .object, Permission XML files end with .permission.

This is the reason why I am so keen on helping @aidan-harding move forward with his current contributions #3413 and #2133

Does that make sense to you @oowekyala ?

[oowekyala]

XML XPath rules would work but only when the file extension is .xml. In Salesforce whatsoever the extension is different. Object XML files end with .object, Permission XML files end with .permission.

Yes but XML Java rules would have the same problem. Maybe I misunderstood, but I was opposing XPath rules to rules written in java, since you wanted to know how to write java rules for an xml dialect.

[ankushsomani09]

Late to comment.
But we were able to run xpath rule on workflow files.
To do that we renamed the file type like this in our temporary folder which were targeted for scan.
<mapper type="glob" from="*" to="*.xml"/>
So we can run the xpath xml rule on any type of salesforce metadata file( which is almost like xml file internally) just by changing the file format.

Our rule was like this :
<![CDATA[//Workflow//alerts//recipients//type//text[@Image="user"]]]>