Unlinked specifications in Applications Profile in Pega 7.1.7
We just completed a comprehensive 4 months POC at a client location and are in the process of starting inception. Since the application is multi-country implementation we have created a framework layer as well as an implementation layer for a model country. As an entry for the inception we have to generate an application profile document for the POC for a requirements gap analysis. The plan going forward is to expand the POC to a full fledged application.
The application has 5 case types 3 of which have some steps (multi-step processes) that are identical. For this reason, these processes were defined at the Application Framework Work class level rather than the case level.
The issue we are facing is with process level specifications. If you look at the specifications from the case designer (by clicking on "Configure step behaviour") the specification are being displayed correctly. However, in the generated application profile the specifications for the common processes are being generated as being unlinked or unassociated.
We think the issue could be the implementation class association of the specification, but we could be wrong. The difference between a specification that is linked to a process in the same class as the case type versus the one linked to the process at the Framework Work class are shown in the screenshots attached.
Has anyone faced issues of this nature before? Is this an expected, if unwanted, behaviour? The client is quite excited about using this document as a live tracking document from requirements to application completion. If these specifications need to be manually re-associated, it's going to be huge disadvantage, especially as number of processes and case types are expected to increase.
If this is bug, has anyone faced it and is there a HotFix or work around? Manually updating the specifications everytime the document is generated is alright for now as the number of processes are few, however impractical in the long run.
Any advice on resolving this issue would be greatly appreciated.
***Updated by moderator: Lochan to add Categories; added enhancement request details***
The links don't clearly indicate if the behaviour is "fixed" in 7.2.1. Perhaps I wasn't clear in my post. The issue isn't one of specifications in the framework layer not getting linked to the implementation layer case type.
The case type and the specifications, that it is supposed to link to, are both in the framework. Let me use a concrete example to better illustrate the issue.
I have a framework work class called AppFW-Work I have a case type called Onboarding belonging to the class called AppFW-Work-Onboarding.. In stage one of the case type there are two steps, Application Preparation and DeDuplication. Application Preparation is a multi-step process and is of the class AppFW-Work-Onboarding. DeDuplication is a multi-step process that is common for two other case types and hence has been created in the AppFW-Work class for re-use.
The specifications for both these processes are in the framework and are linked to the processes. However, when I generate the Application profile document, the specification for Application Preparation is linked (since the process is in the same class as the case type) whereas the specification for Deduplication is generated as unlinked as the process is not in the same class as the case type, instead it's in the parent class (AppFW-Work) (at least I suspect this is the reason).
There are no implementatioin level specifications at the moment as the country specific deviations from the framework have not yet been finalised. The implementation layer, at the moment, establishes only the context (model country) of the execution.
I hope my explanation is clearer. Are you able to confirm whether this is the expected behaviour and has been changed in 7.2.1? Since the client is expecting to manage the project going forward, their expectation is that they can simply generate the document at various stages. Manually moving the specification is going to be cumborsome especially as the volume of specifications increase as other phases are added to the project.
I still havent' figured out a workable solution for ensuring that the specifications linked to processes in the Framework Work class are linked to the specific case type when the application profile document. I haven't had a chance to test this in a 7.2.1 environment to confirm the behaviour one way or the other.
It appears that the issue could be due to the way the application profile is generated. It's possible that the document generation starts from a specification and works it's way to a case. This would mean that all specificatioins linked to processes that are not in the same class a case type would be considered as unlinked. If the generation was case type down to specification then I suspect we may not have this problem as the case type association would provide the information on the linkage.
Perhaps this behaviour has been addressed in 7.2.1. Is there any one who has experienced this particular scenario in 7.2.1? It won't solve the issue for 7.1.7 but it is input I can provide to the client.
If my understanding is correct, it's a behavirour driven by how the document itself is generated. It appears that the document is generated starting from the specifications and then tries to find the linkages of those specifications to the case types.
However, if the document were to be generated using the case types as the starting point I suspect we wouldn't have this issue. This is demonstrated by the fact that the specifications are all visible when viewed from the Case type Explorer in designer studio.
I believe this should be a request for enhancement as it is not addressed in 7.2 either per @SantanuBhattacherje
As the generated application profile and the application document do not contain the process images and specifications (they are part of unlinked specification) it detracts from the overall understanding of the documents as the Case specifications appear to have random "holes" in the documents.