Hi, everyone.

Please, excuse me, if it's a wrong place to post this, I just want to share this with other developers. I will gladly move it to any appropriate place suggested.

While working on the project we encountered an issue: we couldn't remember which rules we were changing for which user story and so, sometimes it was hard to make rollbacks or to understand the scope of the item.

Of course, to solve this we could use custom fields on history tab, but it's hard to make people use it correctly and also, you wouldn't know which version of the rule was changed for which JIRA issue.

So, our solution was to integrate JIRA with PRPC to allow developer to choose the JIRA issue during checkin. To achieve this JIRA REST API, and some new PRPC classes were used.

1. Using the REST connection wizard new connector and classes were created.

The request JSON looks like

{  "jql":"summary ~ implement and summary ~ basic",

    "startAt": 0,

    "maxResults": 10,

    "fields": ["summary"] }

First, let's stop on the string "jql":"summary ~ implement and summary ~ basic".

This is an expression in JIRA Query language that searches for Issues, which contain "implement" and "basic" in summary field. We are using the summary field as JIRA give us no way to search by the key using wildcards and contains conditions. The order of words in issue summary is irrelevant in this case.

"fields": ["summary"] - here we determine that we need only summary field in reponse, as it contains all the info we need.

Here is the example of the issue response:

{

      "expand": "operations,editmeta,changelog,transitions,renderedFields",

      "id": "14928",

      "self": "http://url",

      "key": "ISS-339",

      "fields": {

        "summary": "Implement basic abstract class"

      }

    }

The info we need from it is "key" and "summary".

2. To load the data we use the OOTB wizard and example response and request to generate classes and connector:

3. Let's describe the data structure. Only one class is created:

  I guess, the property names are self-explanatory, except for RefPegaObject which stores the pxInsName of PRPC rule that is linked to JIRA issue. We used the dedicated database table for this class. Also, we had no grants for creating the table, so PRPC generated the SQL code for us and we applied it manually. The fields were generated with VARCHAR (32) type and this was not enough, so the size of fields was increased.

4. The data page is used to get issues from JIRA:

The page is set to reload once per interaction. It is used as a source for autocomplete.

5. We have resaved the CheckIn flow action to reference new section, as standard checkin section has no place to add changes.

So, the new section was created that contains the JIRA related changes (autocomplete with JIRA issues) and the standard section. This is how it looks like:

After checkin the data is saved to DB inside the PostCheckInDialogExtension extension activity, which is provided by Pega.

6. As a finishing touch, reports were created, to get all rules by JIRA issue and all issues by Rule.

The Issues by Rule name report can also be seen on history tab (the section here is available, feel free to include whatever you want)

Hope, this will help someone.

One more thing, when you merge branch, pzInsKey is changed during merge process, so the links become outdated. We have an approach to eliminate this, but it's not tested enough yet. If someone wants to read about, I can share it.

Also, you are very welcome to ask questions and suggest improvements : )

Best regards,

Vadym.