We are able to connect to Azure Blob Storage via Account Key. Eventually that turns out to be a REST call with REST url constructed dynmaically based on Storage account name and container name. eg https://StorageAccountName.blob.core.windows.net/ContainerName?restype=container HTTP/1.1,
It works but is not a approved design pattern by enterprise standards. Instead of hitting this url they want us to come via API gateway. Was wondering if there is any way where URL could be customized while creating Azure repository rule.
The only other alternative I could think of is to create a custom repository rule but want to leverage OOTB Azure repository type.
[Edit - Further research on custom repo]
Also can we use custom repository for purging purposes. We read the documentation that custom repository doesn’t support case archival use cases. We are on OnPrem and want to use Azure blob storage for purging and archival- so we want to better understand the limitation of using custom repository for purging.
no, Pega’s OOTB Azure Blob repository builds the URL from the storage account and the Azure endpoint suffix and does not let you swap in an API-gateway URL, so routing through a gateway breaks auth/signing and isn’t supported. If your enterprise wants brokered access, use network controls instead: Private Endpoint + VNet/ExpressRoute (or egress proxy) so traffic is inspected but still targets *.blob.core.windows.net. You can also lock down the account with firewall/IP rules, use SAS with tight scopes, and enable Defender for Storage and logging to your SIEM. Avoid a custom repository for archive: Pega’s purge-and-archive requires a supported repository type, and the docs are explicit that custom repositories are not supported for case archival or File Data Sets. If you only need “purge” (delete) without archive, you can run purge-only and skip the repository entirely. If governance insists on an API gateway, your realistic path is a custom integration for file I/O (outside the repository rule) plus purge-only in Pega, and keep OOTB Azure repo for any archive use cases.
@Sairohith Got a reply from Pega support - pasting it here for everyone’s benefit.
I have contacted the internal product team regarding this matter and discovered that A new service endpoint option has been added to the Azure repository rule form, which offers enhanced flexibility for connecting to repositories configured with private endpoints, including those in Azure US government cloud repositories.
This feature was introduced in Pega versions 23.1.3, 24.1.2, and 24.2.
A new service endpoint option has been added to the Azure repository rule form, providing greater flexibility for connecting to repositories configured with private endpoints, such as those in Azure US govt cloud repositories.
This feature was introduced in Pega 23.1.3, Pega 24.1.2 and Pega 24.2
