These are my favourite tips and tricks. These are only those who me and my colleguages have tried out.
Keep it slim
Functions should do one thing and they should do it well. When you develop it in C# and Visual Studio, it is so tempting to develop a “microservice” in a good way, you add interfaces, implement good patterns, and all of a sudden you get a monolith packaged in a microservice. If your function grows, stop, rethink. Better to see how it input and output bindings can be used. Also orchestration with Logic Apps or Durable Functions can help.
It might be an obvious one, but it is super easy to setup CI/CD for Azure Functions in Azure DevOps. Set it up as early as possible. Don’t rely on publishing from Visual Studio.
Different environments like Production and Staging (Test, UAT, QAT, verification), and DEV are not straight forward anymore, when everything is reactive and micro. But it is good to have at least two setups: one for Production and one for Staging. Especially separating the storage accounts has been proven to be a success story. You can have the same queue name, but different connections. Deploying to Staging and Production will be easier. The functions in different “environments” will write/read a queue with the same name but in different storage accounts.
I also find it convenient to have postfix in the azure function names, like collect-shipments-staging and collect-shipments-production.
If it is possible, use separate resource groups for the “environments”.
Instead of adding queue messages in code, define it as an output. You can even add multiple messages. This saves you instantiating of CloudStorageAccount which is a good thing for performance.
Take Last Run into account
Just check the timer parameter: timer.Schedule.Last for the time when your Azure Function ran last.
This tip is from CloudBurst in Malmö in September 2019. Eventhough your function runs on a consumption plan, the chance is big that your code will run on the same server, which means that you can reuse some resources, like HttpClient.
The issue I got was that indexed columns were there. You can try to remove indexed columns and re-add them. But it is not the best solution. In my scenario, it was an indexed column that I couldn’t remove.
The reason why I use a combination of PnP and CSOM (Load, Update, ExecuteQuery), is that I have not found a way of updating RegionalSettings in PnP.
Tip #1 You don’t need Tenant Admin rights to add a new Site Collection App Catalog
I have seen many blogs, forum threads etc that state that only Global Tenant Administrators can add new Site Collection App Catalogs. The truth is that a SharePoint Admin rights are enough. The trick is to make that SharePoint Admin Account to a site collection administrator of the app catalog site. To be precise the account that adds a new SCAC must have Manage Web Permissions, as stated in error message:
Add-SPOSiteCollectionAppCatalog : Must have Manage Web Site permissions or be a tenant admin in order to add or remove sites from the site collection app catalog allow list
Tip #2 List all Site Collection App Catalogs
To list all the SCACs in your tenant navigate to that url:
Currently, it’s not possible to list all site collections in the tenant that have the site collection app catalog enabled.
The fun fact was that I sherlocked it since I knew my account needed access to the main App Catalog site. So there must be some information that is stored. How is it done a là SharePoint – yes, it is stored in a hidden list. Like in the olden days. 🧐
This is about a topic brought up by Waldek Mastykarz: Just because you can should you use the Office 365 CDN. In my post I want to take a closer look at the private CDN option in Office 365. Please note, the whole thing is subject to change, and it reflects the circumstances at the time of writing – 2019-08-26.
I use Modern Team Sites and Communication Sites. Is the Private Office 365 CDN something for me?
No, the urls are changing. You cannot “hardcode” them. Automatic URL Rewrite works only on classic Publishing Sites.
I have Provider Hosted Add-Ins. Is the Private Office 365 CDN something for me?
No, the referrer needs to be a subdomain of sharepoint.com.
The whole point of having a private CDN is that it is not available for strangers. But when you enable it, you’ll see an eligible warning:
WARNING: This is a feature built on a 3rd party application with privacy and compliance standards that differ from the commitments outlined by the Microsoft Office365 Trust Center. Any data cached through this service does not conform to the Microsoft Data Processing Terms (DPT) and is outside of the Microsoft Office365 Trust Center compliance boundaries.
If you remove an asset from the private cdn origins, it takes up to 15 minutes for the link to be invalidated. Opposed to an immediate effect for a direct link to an asset in a document library.
To keep it more secure, the default private cdn origins should not be included, especially */SITEASSETS, Because site assets can have important information, and this makes every single site assets library vulnerable, asterisk means all.
Even the CDN Policies should be restrictive.
Overall, if the usage area is small, the performance gain is little, we should not enable it at all. Because: any cached data in a private Office 365 CDN is outside of the Microsoft Office365 Trust Center compliance boundaries.
I have tried the private CDN. My setup was a document library with three versions of a picture that was 2,4MB that I put to three different libraries:
On the publishing site I inserted three images on a page and compared the load time in the DevTools. During this test I had Cache Disabled. I got following results:
private, public, nocdn
3.04s, 3.03s, 3.24s
1.78s, 1.77s, 1.75s
1.99s, 1,95s, 3.32s
1.67s, 0.73s, 0.72s
1.73s, 1.71s, 1.97s
1.60s, 1.58s, 1.67s
So only once I got a bigger difference, otherwise it took the same time to load a picture from a document library without CDN.
To be fair, it is a very simple performance test. Tests with bigger files, different geographical locations would probably give a more detailed view of that. And still, without a URL Rewrite that is only present on Publishing sites, you cannot take use private cdn origins.
Private CDN in Office 365 can be interesting in future, but today, the usage is narrow (only publishing sites can refer to assets in a private CDN), the performance gain is little and lower security makes it to a bad choice.
There are many resources on the internet that list _layouts/15 urls in SharePoint. Some are outdated, some are too short, some are to long. Here is my list of the urls, that I am going to update when I need. All the urls start with [Your-Tenant].sharepoint.com/sites/[Your-Site]/_layouts/15/
Here we go:
viewlsts.aspx – Site Contents, Modern View
viewlsts.aspx?view=14 – Site Contents, Classic View
appinv.aspx – Grant Permissions to an App
appregnew.aspx – Register a new SharePoint Application
appprincipals.aspx – List Registered Add-Ins
CreateGroup.aspx – Create Site page (Team and Communication)
TA_AllAppPrincipals.aspx – List all app principals
SwiftKey is a keyboard app for iOS and Android, it adds a new virtual keyboard and it provides the Chuvash one among others.
Here is my review of Swiftkey from the perspective of a person who writes in Chuvash on the mobile.
The fact that it has the Chuvash keyboard map is awesome. There is no official Chuvash keyboard in iOS, Android, MacOS, Windows (well you can add Chuvash, but you won’t get the Chuvash letters). Only Linux has the built-in Chuvash keyboard.
It has a built-in Chuvash dictionary, so that can provide suggestions. It also can learn from your typing. Although there is an issue with the suggestions, see below.
The Chuvash characters with diacritics are right: Unicode and Cyrillic, not their look-alikes from the Latin set. It is important: if people use the same characters, they can find more on Google.
Actually I don’t want to call it negative things, many of them are just missing features. I hope with that review I can get in contact with the Swiftkey team and improve the app.
Chuvash letters with diacritics are “hidden” behind their “siblings” without diacritics. To get ӗ you have to long-press е then е and ӗ will pop up. The Chuvash letters should be in the front. Some typical Russian letters can be moved to the back, e.g. ц, щ, ж, д, г etc. Those “Russian” letters are used in Russian loanwords. See the proposal of the keymap below.
There are “too many” characters, the keyboard buttons are too small on the mobile. This issue is the same for the Russian keyboard. Since Chuvash has fewer Core Chuvash letters, we could take the rare ones to the back, it would be okay to long-press to get them: г, д, ж, з, щ etc.
One character is used a lot, it is a simple hyphen “-“. It is between words and small additions to express questions, wondering, nice asking: -и?, ши?, -ҫкӗ, -ха etc. Also in the “collection words”: сӗтел-пукан (furnitures), сас-хура (rumors). It is heavily used and having the hyphen somewhere in the front, would make typing a lot faster in Chuvash.
Swiftkey should be at least tri-lingual, not bi-lingual. It is limited to 2 languages only on the iOS (on Android you can add up to five languages). Consider a typical Chuvash guy who needs to write in Russian in his daily life. He also writes in Chuvash in social networks. Occasionally, he has to input latin letters (domain names, e-mail etc), meaning he needs the third language – English.
The dictionary used for the suggestions seems to use a mix of Cyrillic diacritics and their latin look-alikes: ӑӗҫ. They are not treated as the same letters, therefore many right words are excluded from the suggestions. A solution for that would be a simple find and replace of three letters (the capitals and versals): Latin A with breve to Cyrillic A with breve, Latin E with breve to Cyrillic E with breve. Latin C with cedilla to the Cyrillic C with Cedilla. But even Latin Y with diaresis should be replaced with Cyrillic y with double acute.
Since many “Russian” letters are not used a lot, they could be brought back and accessed by long-pressing the keys. I would suggest, keep the existing keymaps (Russian Compact, Russian Phonetic, Russian Full), but also add a new keymap: “Chuvash Compact”. Here are the three rows of characters.
Top row (10 chars) : й ӳ у к е н ӗ ш ӑ х
Middle row (10 chars): ҫ ы в а п р о л – э
Bottom row (8 chars): я ч с м и т ь ю
The “long-pressed” characters:
к: к г (why: simplified: they represent allophones in Chuvash)
е: е ё (ё to type some Russian loanwords)
ш: ш ж (why: simplified: they represent allophones in Chuvash)
х: х ф (historically ф was transformed to х or хв, still not very common letter)
ҫ: ҫ щ (why: simplified: they represent allophones in Chuvash)
п: п б (why: simplified: they represent allophones in Chuvash)
-: – ! (why: hyphen is used a lot in the words, the exclamation mark is used often after onomatopoetic words)
с: с з (why: simplified: they represent allophones in Chuvash)
т: т д (why: simplified: they represent allophones in Chuvash)