A tale of two offices
While developing an app for the first time that uses Azure Cosmo DB, I came across the situation where the app could connect to the Azure Cosmo DB service when working at home, but not while developing on the work office computer.
I immediately felt a sense of deja-vu.
On a previous app, I was using Azure Service Bus and came across the same issue - the connection was blocked when in the work office by the corporate firewall. When working at home, I was no longer behind the firewall.
The resolution back then was to configure the Service Bus client to use a different protocol and transport for communicating with Azure Service Bus.
Would there be a Cosmo DB version of the Service Bus client’s TransportType option?
A quick bit of Bing’ing lead me to the following Microsoft post about client connection modes:
If your application runs within a corporate network with strict firewall restrictions, gateway mode is the best choice because it uses the standard HTTPS port and a single DNS endpoint.
Without further ado, I updated my code while in the work office and the issue was immediately resolved.
cosmoClient = new CosmosClient(connectionString: cosmoConnStr, new CosmosClientOptions
{
ConnectionMode = ConnectionMode.Gateway
});
Cosmo DB Client
id property not defined
Unlike the Azure Data Table, a specific property called id needs to be part of the class definition.
This could be auto-generated, adding the option below, which will generate a GUID:
new ItemRequestOptions { EnableAutomaticIdGeneration = true }
I am opting for an id that I will generate based on what will be the unique properties for each instance - in SQL world, a composite primary key.
https://stackoverflow.com/a/64124223/641165
Azure function not returning JSON to JS Fetch API