What is Microsoft Fabric?

Microsoft Fabric is an end-to-end analytics and data platform designed for enterprises that require a unified solution. It encompasses data movement, processing, ingestion, transformation, real-time event routing, and report building. It offers a comprehensive suite of services including Data Engineering, Data Factory, Data Science, Real-Time Analytics, Data Warehouse, and Databases.

With Fabric, you don’t need to assemble different services from multiple vendors. Instead, it offers a seamlessly integrated, user-friendly platform that simplifies your analytics requirements. Operating on a Software as a Service (SaaS) model, Fabric brings simplicity and integration to your solutions.

Microsoft Fabric integrates separate components into a cohesive stack. Instead of relying on different databases or data warehouses, you can centralize data storage with OneLake. AI capabilities are seamlessly embedded within Fabric, eliminating the need for manual integration. With Fabric, you can easily transition your raw data into actionable insights for business users.

Read more here;

https://learn.microsoft.com/en-us/fabric/get-started/microsoft-fabric-overview

idTokenClaims vs accessTokenClaims

n the context of authentication, an “idtokenclaims” refers to the specific user identity information contained within an ID token, used primarily for verifying a user’s identity, while an “access token” grants authorization to access specific resources on a server, essentially acting as a key to access protected data based on the user’s permissions; meaning, an ID token tells you who the user is, while an access token tells you what the user is allowed to do.

Key differences: 

  • Purpose: An ID token is used for user authentication, displaying user information on the front-end like name and email, while an access token is used to authorize access to specific resources on a server. 
  • Claims: ID token claims usually include basic user information like name, email, and user ID, while access token claims specify the allowed scopes or permissions for a particular resource. 
  • Usage: A front-end application typically directly reads and displays information from an ID token, while an access token is sent with API requests to the server to verify authorization. 

Example:

  • ID token claim example: When you log in to a website, the ID token might contain your username and email address, which the website can display on your profile page. 
  • Access token claim example: If you want to access your private documents on a cloud storage service, the access token would specify your permission level (read only, read/write) to access those documents. 

Extending HttpClient With Delegating Handlers in ASP.NET Core

Delegating handlers are like ASP.NET Core middleware. Except they work with the HttpClient. The ASP.NET Core request pipeline allows you to introduce custom behavior with middleware. You can solve many cross-cutting concerns using middleware — logging, tracing, validation, authentication, authorization, etc.

But, an important aspect here is that middleware works with incoming HTTP requests to your API. Delegating handlers work with outgoing requests.

Read more here

https://www.milanjovanovic.tech/blog/extending-httpclient-with-delegating-handlers-in-aspnetcore

App Registration vs Enterprise Applications

All applications that get registered in AAD, in the tenant, two types of objects get created once the app registration is done.

  • Application Object
  • Service Principal Object

The Application Object is what you see under App Registrations in AAD. This object acts as the template where you can go ahead and configure various things like API Permissions, Client Secrets, Branding, App Roles, etc. All these customizations that you make to your app, get written to the app manifest file. The application object describes three aspects of an application: how the service can issue tokens in order to access the application, resources that the application might need to access, and the actions that the application can take.

The Service Principal Object is what you see under the Enterprise Registration blade in AAD. Every Application Object (created through the Azure Portal or using the Microsoft Graph APIs, or AzureAD PS Module) would create a corresponding Service Principal Object in the Enterprise Registration blade of AAD. A service principal is a concrete instance created from the application object and inherits certain properties from that application object. A service principal is created in each tenant where the application is used and references the globally unique app object. The service principal object defines what the app can actually do in the specific tenant, who can access the app, and what resources the app can access.

Similar to a class in object-oriented programming, the application object has some static properties that are applied to all the created service principals (or application instances).

You can read more on the following objects here: https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals

Reference

https://learn.microsoft.com/en-us/training/modules/implement-app-registration/2-plan-your-line-business-application-registration-strategy

Last Run Date on a Stored Procedure in SQL Server

We starting to get a lot of stored procedures in our application. Many of them are for custom reports many of which are no longer used. Here is a query that can be run on the system views in SQL Server 2005 – 2022 that would tell us the last date a stored procedure was executed?

SELECT o.name, 
       ps.last_execution_time 
FROM   sys.dm_exec_procedure_stats ps 
INNER JOIN 
       sys.objects o 
       ON ps.object_id = o.object_id 
WHERE  DB_NAME(ps.database_id) = '' 
ORDER  BY 
       ps.last_execution_time DESC  

Reference

https://stackoverflow.com/questions/595742/last-run-date-on-a-stored-procedure-in-sql-server