Written by Breaking best practices established by an ISV for the integration of their product into an enterprise architecture can increase integration costs significantly. A simple break in naming conventions can introduce days of additional effort for the initial integration and may increase risks of breaking core functionality on subsequent product upgrades.
I’ve just spent an hour patching and verifying a fix for one broken product feature in PRPC caused by an integrator ignoring the practices around naming for starting workflows. The consequences of ignoring the naming convention generally causes new work creation through the simplified APIs to be incorrect in addition to causing several other features, such as reopening resolved work, to fail or operate incorrectly when they are invoked.
Rather than correct the naming of the flow during integration, the systems integrator created new mechanisms to reopen or reconsider the work during their initial implementation. They then created secondary mechanisms that copied the work creation implementation from the lower level implementation intended for internal PRPC operations, adjusting the copy to build out a modified work creation API. They subsequently introduced the new API broadly by copying other restricted out-of-the-box features they needed into new features and removing the standard work creation calls therein to replace them with their customized work creation mechanism calling their uniquely named workflows. In all, they increased their level of effort in implementation and unit testing from a few minutes to several days by reengineering these internal product features – mostly out of apparent ignorance regarding the naming conventions and API hooks available for customization.
The fix is relatively simple – create a new workflow called NewWork and add a call to the incorrectly named workflow, then terminate the NewWork workflow. This fix reenables the out of the box features, but there are still hacks present in the system via the copied code that can break on an upgrade of the product should the work internals change in a subsequent product release.
The complete fix would involve renaming the flow and removing the copies