Linking JIRA issues with PRPC rules on checkin

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,


**Moderation Team has archived post**

This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.


Keep up to date on this post and subscribe to comments

April 21, 2016 - 11:22am

Hi Vadym,

Very impressive. I think this is one of the most common challenges faced by project teams - how to effectively track rule changes for a bug fix or feature implementation. I really like the way you went ahead and implemented the solution. 

For me this is one of the most interesting and impressive mesh posts I ever came across, so very tempting to ask you many questions.

But let me start with following few questions related to check-in process:

  1. You said you replaced the section in check-in flow action. How easy was this? Any challenges faced while implementing this new check-in section? I am asking this question because sometimes when we are customizing an OOTB feature we hit into road blocks like final rules that cannot be modified, then have to recreate entire chain of rules to accomplish what we want.
  2. I think there are few rule types like Access Roles that do not have check-in process. How are you handling such rule changes? I think even data instances also fall under this category. Or may be these instances fall under a minority of changes and hence can be ignored!
  3. When a check-in is done, you are saving the details (JIRA issue linked with Pega rule's pzInsKey) in the dedicated table you explained in step 3. You are not saving JIRA ID as part of rule data right? Is my understanding correct?

I have the experience of using Pega PMF product (Project Management Framework?) integrated with PRPC. Similar feature you implemented is there as part of PMF - PRPC integration features. For every check-in we used to tag Bug ID/User Story ID/Task ID, but not sure whether we used to manually enter the bug ID or an auto-complete was there to list the valid bug IDs!!! Did your team considered this option of using PMF? Of course I think it has to be separately licensed!!!

Thanks for sharing this with such details.


April 22, 2016 - 6:43am
Response to Muralik7

Hi, Murali

Will try to answer your questions:

1. The Flow Action CheckIn is available, but the referenced section is Final, so I made a wrapper section, which included the final section plus my changes.

2. Non-versioned rules are under progress right now, I guess we will just go with adding the UI to History tab which will aloow to link them with JIRA issues.

3. Yes, you correct, there are no changes to rule data, as we don't want to have some issues after PRPC upgrade or something like that : )

We did not use the PMF as we need this data strictly for developers. The managers, QAs and analysts will still use JIRA. As I understand, PMF is good to use only if it's used by the whole team?


April 21, 2016 - 12:33pm

It's very useful article

April 21, 2016 - 7:52pm

Hi Vadym,

I concur with all other comments. This is the kind of stuff can really make people want to come the community. With some refinement, I think this can go to pega exchange: https://pdn.pega.com/pega-exchange-guidelines.  Of course, it is entirely up to you. Again, thanks for sharing and well-deserved compliment!

April 22, 2016 - 8:51am
Response to KevinZheng_GCS

Thank you, Kevin.

Commiting something to Pega exchange would be a great thing : )

Thanks for suggestion, we will try to refine and test the product and make it ready for pega exchange!

April 28, 2016 - 5:50am

Hi Vadym,

It is indeed a very useful article and information for projects where we do need to synch up the daily activities in the system like bug fixing with similar tracking products like JIRA, Confluence etc.

Do you know if the REST APIs are also accessible via the Cloud instance of JIRA? or is it restricted to the server installation only.

April 28, 2016 - 7:08am
Response to DHARA001

Hi Anoojit,

I don't know, but don't see any reason why it wouldn't work : )

April 28, 2016 - 7:15am
Response to VadymTurovskyi

with cloud instance, normally some kind of whitelist needs to be customized to allow incoming requests.

April 28, 2016 - 9:26am
Response to KevinZheng_GCS

Hi Kevin, Vadym,

I just came to know that if we are using JIRA on the cloud, then we need teh Atlassian Connect to build the add ons in JIRA and then be able to use the REST APIs.

Thanks to both for providing your insights.

May 2, 2016 - 9:30am

Hi Vadym

This is very helpful in our day to day development. This helps to track the changes made.

Here are my thoughts:

     I think you are doing this process while checking in a rule (While doing a check in we are adding a user story details to the rule). My take would be , we do the same process while we creating a rule also. The below section should be embedded on rule creation/save as form. This will help us to track the changes made for the data instances also. However we will not be able to track changes made for existing data instances.


Please share your thoughts.



May 16, 2016 - 3:51am
Response to SamanthReddyC

Hi Samanth

Yes, I agree with you, this would be a great thing. Also, links with Jira issues should be deleted on rule removal (e.g. it was created on error). As soon as project activities will give me some time, I will research this and hopefully develop some solution.

Thank you

December 2, 2016 - 12:07pm
Response to SamanthReddyC

I agree, this may be needed... but are you aware of any extension point that can be used for persisting JIRA data while we do SAVEAS.

May 17, 2016 - 1:55pm

One of the Pega partner, Serendebyte, already has created different plugins to link JIRA, TFS etc to Pega applications. In fact you can close JIRA task from Pega rule check in UI.

May 20, 2016 - 2:59pm

Thanks for the mention Vivek Pandey. Nice work Vadym.

Over the past year and half Serendebyte has created a toolkit to integrate various ALM products with Pega application development lifecycle. The toolkit currently supports ALM tools including JIRA, Rally, Microsoft TFS and HP AGM.

The toolkit allows to

  - link all rule creation and updates to ALM artifacts

  - Update the ALM artifact from Pega during checkin/rule creation

  - Configure specific ALM artifact type to include to link

  - Provides developer dashboard to view ALM assigned artifacts in Pega developer portal

  - Provides impact analysis combining information from linkages created in Pega and ALM tool which is one of the key features that vastly improves Pega application development productivity for tasks like code review and application maintenance.

  - Provides traceability and reports for release documentation

I have pasted some screen shots of the toolkit in action. Please feel free to ping me if you need more information.

Serendebyte_PAT_Overview Images.001.pngSerendebyte_PAT_Overview Images.002.png

Serendebyte_PAT_Overview Images.003.png

Serendebyte_PAT_Overview Images.004.png

Serendebyte_PAT_Overview Images.005.png

Serendebyte_PAT_Overview Images.006.png

Serendebyte_PAT_Overview Images.007.pngSerendebyte_PAT_Overview Images.008.pngSerendebyte_PAT_Overview Images.009.pngSerendebyte_PAT_Overview Images.010.png



December 29, 2016 - 11:00am

Hi Vadym,

I am trying to implement the same like you. Can you let me know the JIRA resource URL you used? Also did you run any compatibility test in the Altassian site? I was advised by the JIRA support team to run a compatibility test with 6.4.13 datacentre version. The JIRA we are using is within the client netwrok. Does it require authentication?