Building a better world with people, process, & technology

PRPC – Adhering to NewWork Naming

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 of the internal code, moving functionality into the hooks provided by the out of box APIs instead of hardcoding it into copies of those APIs. Rather than introduce operational risk and a large immediate regression testing effort by resolving this fully, the full fix is deferred until such time as an upgrade is undertaken as part of the cumulative technical debt from a poorly conceived implementation.

2 Comments

  1. Fernando's Gravatar Fernando
    August 16, 2017    

    Hello David Picard, I would like, if possible, your email. I do not know if you would have time or interest. It’s that I have a server in the clouds and I do not understand anything about linux (laughs) and I’d like to put some security rules in place. Grateful.

    • August 17, 2017    

      You might want to consider posting your questions on the relevant post – this post is in the context of PRPC or Pega7. My post on our start with AWS might prove helpful – if not pose your question there so the answer can be shared with all users.

Leave a Reply to David Picard Cancel reply

Your email address will not be published. Required fields are marked *

Whitepapers & Presentations

Contact us for access

We are proficient in BPM delivery with hands on platform expertise in Pegasystems PRPC platform!