Question
Cognizant Technolgy Solutions
IN
Last activity: 20 Apr 2023 6:32 EDT
Upload large docs to another system from Pega portal
Hi Pega practitioners/Gurus ,
Pls refer to the following scenarios and let me know about your thoughts on what could be the best design for this.
- the client uses a customer service application (CPM FW) where from within an Intent task the CSR is expected to upload multiple large docs (each up to 10mb).
- Although the functionality requires a Pega upload look and feel, the uploaded doc is supposed to be sent over to another system which is on Amazon S3. (Through rest services using file type binary attachments).
- There's no limit to the number of docs the CSR can upload on a case.
- As soon as the upload happens, the intent task is supposed to be refreshed with the link of the uploaded doc(a pre-signed URL) in the embeded "Documents" section.
- There can be 100s of CSRs who might be uploading these documents concurrently during the peak hour in prod.
Considering the size of the attachment, the approach we have taken is asynch service calls using Queue processors to send the attachments over to the non-pega systems and reconciliation to Pega case using notification channel; the high level details of this is described below,
Hi Pega practitioners/Gurus ,
Pls refer to the following scenarios and let me know about your thoughts on what could be the best design for this.
- the client uses a customer service application (CPM FW) where from within an Intent task the CSR is expected to upload multiple large docs (each up to 10mb).
- Although the functionality requires a Pega upload look and feel, the uploaded doc is supposed to be sent over to another system which is on Amazon S3. (Through rest services using file type binary attachments).
- There's no limit to the number of docs the CSR can upload on a case.
- As soon as the upload happens, the intent task is supposed to be refreshed with the link of the uploaded doc(a pre-signed URL) in the embeded "Documents" section.
- There can be 100s of CSRs who might be uploading these documents concurrently during the peak hour in prod.
Considering the size of the attachment, the approach we have taken is asynch service calls using Queue processors to send the attachments over to the non-pega systems and reconciliation to Pega case using notification channel; the high level details of this is described below,
- We'll be using the Pega's OOTB upload icon as the UI, which gives a local action in a modal window to upload/drag and drop files.
- On submit of this Attach-File local action, we'll be calling a Queue processor (running on background processing nodes) which will handle the upload service calls.
- After the call to the QP, the attachment stream (pyAttachmentPage.pyAttachStream ) will be removed from clipboard so that the user's current session (Jvm's of the web user nodes) wont have to bear the high volume of the attachments.
- Once the QP has processed the attachments through REST service calls, we'll be publishing the response received to a Notification channel.
- The Intent task will be subscribed to the same channel so when the notification is published, the response will be used to update the live case UI to show the latest links.
Pls share if you see any concerns or have any thoughts on how the requirement can be implemented in a better way.
Thanks,
Arka
Pegasystems Inc.
IN
Configure content management in integration tab of the application. Using queue processor is over engineered solution.
Cognizant Technolgy Solutions
IN
@SriHarsha Anika Hi Sriharsha,
Thanks for your inputs!
During the initial discussions, the other side confirmed that the only way to connect to these repositories were the couple of Rest services they shared.
Also, we have multiple AccessGroups which all use the same application, but have different case types - this feature is applicable to only one case type.
Also, there is a preexisting document section inside the case perform area where the links to these docs have to be shown using a specific preSignedURL algorithm.
Considering the above constraints, we have taken the previously mentioned approach.
Thanks,
Arka
Pegasystems Inc.
IN
It is not true that the CMIS configuration is applicable only to one case type.
This configuration is at application rule - spread across to entire application level not at access group level.
If there are multiple application rules being accessed by different access groups then configure CMIS at built on application level up in the application hierarchy.
Predefined Presignin URL can be achieved as well, upload and download utilities are preexisting, you have to maintain the authentication, URL in application settings and invoke the OOTB utility.
Cognizant Technolgy Solutions
IN
What I meant is the business requirement is applicable to only one case type.
Also, like I said, the only way to access the repository is through REST services. Can you pls share some examples where CMIS is implemented using REST services?
Thanks for taking time to respond! It helped!
Arka