Question
Cognizant
CH
Last activity: 19 Sep 2017 17:05 EDT
Linking one Data-WorkAttach-* instance to multiple Cases
Hi,
We have a requirement that we receive documents from a Document Management System via service calls and some of the documents need to be attached to multiple cases. First I thought it was easy, as Attachments are referenced via a Link from the Cases (Work-* --> Link-Attachment --> Data-WorkAttach-File). But it turns out that the key for Data-WorkAttach-* consists of the Case's pzInsKey as well which it is linked to: pxRefObjectKey, pxAttachKey. Also pxRefObjectKey is used for determining permissions for the attachment.
Has anyone encountered an expectation like that (one attachment to multiple cases)? How can we solve that?
Thanks,
Attila
Accepted Solution
Pegasystems Inc.
US
Hello Attila,
Unfortunately, I think you might be right. OOTB, the platform assumes there is a relationship between attachments and work objects. That said, if you create your own table for attachments, you can definitely store an array of pointers to it in the clipboard and open them yourself via an activity. The OOTB attachment code should act as a good guide, since I don't think there's any technical reason your design can't be implemented in Pega, it's just not the way we did it.
Thanks,
Mike
Pegasystems Inc.
US
Hello Attila,
While I haven't seen this requirement before, I think you are on the right path. I think you'd need to have the Data-WorkAttach-File key reference the first work object that created it, but subsequent work objects could get a Link-Attachment object who's pxLinkedRefTo property points to the Data_WorkAttach-* object and who's pxLinkedRefFrom points to the new work objects.
I'm not sure how you deal with the permissions issue, which might be a sticking point. I'd trace that and see what rules are looking at things and if you can do something about it.
Thanks,
Mike
Cognizant
CH
Hello Mike,
Thank you for your answer. I was thinking of something similar: having a "master" work object for permission handling and linking the attachment to other cases as well. However in our current situation cases are equal, I cannot choose a "master", it would be unnatural from the document model's perspective.
I guess the issue is that in our situation the attachment is not created by a work object, it just comes from a service request and it is not specifically tied to a case. Pega's attachment handling data model seems to be designed with tightly coupled cases and attachment in mind. We might end up creating a new Org-Data-* class for our needs instead of forcing our data into Pega's OOTB attachment model.
Thanks,
Attila
Accepted Solution
Pegasystems Inc.
US
Hello Attila,
Unfortunately, I think you might be right. OOTB, the platform assumes there is a relationship between attachments and work objects. That said, if you create your own table for attachments, you can definitely store an array of pointers to it in the clipboard and open them yourself via an activity. The OOTB attachment code should act as a good guide, since I don't think there's any technical reason your design can't be implemented in Pega, it's just not the way we did it.
Thanks,
Mike