Why reverse engineer Primavera Unifier?
I have been working with Primavera Unifier, for a year now. After working with it for a month, it wasn't very difficult to see that Unifier had some limitations, that would hinder our ability to scale, and integrate with our many solutions. After studying Primavera Unifier for the next, month I found that most of the configurations, permissions, and data was all stored in the Database. Once I learned this, I spent the next 10 months, studying each screen and page in Unifier, and finding the equivalent data source in the database. This has enabled me to be able to build tools to help enhance the Unifier experience.
Limitations with Primavera Unifier
- Can't add buttons
- Wouldn't it be cool if we could add a button, that could execute a javascript command that we program? Would it be cool, if we could program a button to perform certain functions. Currently this is a limitation in Unifier, we are limited in our ability to interact with the Bp's.
- No external calls to a web service
- One of the largest limitations, is not being able to make an external service call. There's a lot of times we would love to integrate with peoplesoft, or update information in an external system. Or pull in information from an external system, but not have to store the information.
- Managing permissions at a shell level
- If you are a large organization with a lot of properties, then managing the permissions on this can be quite cumbersome. Unifier only has shell level permissions, meaning, each shell, has ownership of its own set of permissions. When you are trying to scale what you really need is one set of permissions for all of your properties. The Unifier model makes it difficult to support the permissions for such large amount of shells, and it also it makes it slow when you have a large amount of changes to make. In the database, to support about 700 employees, creates about 12,000,000 permission records in unifier.
- Unable to push permissions down a shell hierarchy
- Again when scaling to support thousands of properties, most organizations of a hierarchy to help support all the properties. A regional manager may have access to 300 properties, but the only way to give him access to those 300 properties, is to go to each property and add the permission. If you have multiple levels of shells, this becomes increasingly cumbersome.
- Unable to update data directly in the database
- Unfortunately tampering with the database invalidates the warranty. Which means the only way to update the database is through the web service, which is obviously slower.
- Unable to export pieces of translations
- If you have a large Unifier project, and you want to be able to translate certain BP's above others, you can't. You can only translate all the strings at once.
- Another issue, if you add more strings, and you just want to translate the new strings, Unifier does not allow you. It always exports all the strings, and leaves you no ability to figure out which strings have been already translated.
- Unable to deploy permission, and configuration changes
- When your supporting an enterprise level solution, you typically need a few lanes of promotion. Currently the only piece you can transfer between environments are uDesigner modules. You can't do configurations and permissions. Which means these pieces have to be deployed manually. For a BP you are looking at about 350 unique configurations, any mistake, or missed click can drastically alter your end result.
- Unable to delete, or hide records, bps, workflows, setups, and configurations.
- If a mistake is made in a module, or workflow, there is no way to delete, or hide the module from uDesigner, or configurations properties. This makes for a messy environments, as the only way to distinguish them is through a naming schema.
- No Encrypted sensitive data
- If storing sensitive data, like ssn's, credit card numbers, etc. There is no way to encrypt this information at the database layer.
- Wouldn't it be cool if we could add a button, that could execute a javascript command that we program? Would it be cool, if we could program a button to perform certain functions. Currently this is a limitation in Unifier, we are limited in our ability to interact with the Bp's.
- One of the largest limitations, is not being able to make an external service call. There's a lot of times we would love to integrate with peoplesoft, or update information in an external system. Or pull in information from an external system, but not have to store the information.
- If you are a large organization with a lot of properties, then managing the permissions on this can be quite cumbersome. Unifier only has shell level permissions, meaning, each shell, has ownership of its own set of permissions. When you are trying to scale what you really need is one set of permissions for all of your properties. The Unifier model makes it difficult to support the permissions for such large amount of shells, and it also it makes it slow when you have a large amount of changes to make. In the database, to support about 700 employees, creates about 12,000,000 permission records in unifier.
- Again when scaling to support thousands of properties, most organizations of a hierarchy to help support all the properties. A regional manager may have access to 300 properties, but the only way to give him access to those 300 properties, is to go to each property and add the permission. If you have multiple levels of shells, this becomes increasingly cumbersome.
- Unfortunately tampering with the database invalidates the warranty. Which means the only way to update the database is through the web service, which is obviously slower.
- If you have a large Unifier project, and you want to be able to translate certain BP's above others, you can't. You can only translate all the strings at once.
- Another issue, if you add more strings, and you just want to translate the new strings, Unifier does not allow you. It always exports all the strings, and leaves you no ability to figure out which strings have been already translated.
- When your supporting an enterprise level solution, you typically need a few lanes of promotion. Currently the only piece you can transfer between environments are uDesigner modules. You can't do configurations and permissions. Which means these pieces have to be deployed manually. For a BP you are looking at about 350 unique configurations, any mistake, or missed click can drastically alter your end result.
- If a mistake is made in a module, or workflow, there is no way to delete, or hide the module from uDesigner, or configurations properties. This makes for a messy environments, as the only way to distinguish them is through a naming schema.
- If storing sensitive data, like ssn's, credit card numbers, etc. There is no way to encrypt this information at the database layer.
No comments:
Post a Comment