Metastorm 9 is a great product. It’s a leap forward on its v7.x parents and despite its initial productivity slow downs, you generally feel like you’re building a more solid / stable application with v9. This being the case I do have a small number of gripes to get off of my chest that focus on (blame;-) the product testers over at Metastorm. Did they actually try and deploy anything on a 64-bit system during testing?
1) Designer incompatibility
My last post covered this point, so I don’t plan to go into much detail here but releasing a product that fails to deploy your solutions on a 64-bit install just because the COM objects the application uses can’t be loaded into the executing process is poor design. There are ways to load 32-bit assemblies without completely neglecting the fact you need to work with non 64-bit compatible COM objects for your product to work properly.
2) Remote Deployment Security Validation
So if you’ve gone with installing your engine to a 64-bit machine, realized that you cannot deploy from the Designer application on that machine and moved the Designer onto a 32-bit machine, you’ll need to adopt remote deployment. To deploy to the 64-bit engine, you have to point the Designer install to the DeploymentServiceConfig.xml file being hosted in the escripts folder of the engine server. This can be done during the Designer installation, via the registry or via the Designer options. This xml file contains the tcp location of the deployment service(s). The service is a Windows Communication Foundation service with a tcp endpoint (hence the need for net.tcp port sharing on the server).
What you may find if you are running Metastorm BPM v9.0 or v9.01 is that deployment fails and you are told that ‘A call to SSPI has failed’ and are advised to review the inner exception. Interesting when a stack trace is not displayed to you via the Designer so you are not able to review the inner exception. SSPI is the Security Support Provider Interface for windows operating systems and it’s job is to accept windows credentials from an application (via RCP, Named Pipes, DCOM, Winsocks2 etc) and authenticate those credentials against the operating systems security accounts manager (SAM) database. So in effect its the security middleman. Clearly in this case, either the windows account used by the remote Designer or the account running the WCF service locally on the server is not able to be passed to SSPI (i.e. call failed). Hotfix 184.108.40.206 sorts this issue however, which is great, but come on Metastorm, how does your initial product ship with an inability to fully support remote deployment of solutions? That’s just sloppy on the part of the product testers and quality control staff, especially when the SR1 release fails to address the issue and a hot fix is needed?
Why in v9 am I still finding that the service/database password(s) provided during the installation of the server are stored in the registry? Maybe those who have not noticed this yet may think that sharing this information is a security risk in itself? It should be. Metastorm need to change this. Passwords sucked into any application should NEVER have that password stored in clear text anywhere on the system, full stop. Encryption is not hard to come by. You can read a password into the application, encrypt it down to a persistent store, then decrypt it when it is read back into the application (even a simple 8-bit key DES encryption scheme is better than nothing). Application security 101.
Rant over 😉