Facturation Azure dans un contexte CSP, la suite !

Je vous avais parlé de la facturation Azure dans un contexte CSP il y a quelques jours, et comme promis je reviens à la charge dans un nouveau billet pour aller encore plus loin et vous présenter une solution très sympathique du nom de Peek.

Azure Usage / Billing Analytics est une solution basée sur du PaaS Azure qui permet de simplifier la collecte des données d’utilisation pour différents cas d’utilisation (Enterprise Agreement, CSP et Direct Azure Subscriptions) et fournit des visuels détaillés pour l’analyse de données en temps quasi réel (sous forme de Webjobs).

Les exemples de rapports basés sur Power BI peuvent être utilisés pour créer plusieurs tableaux de bord centrés sur les abonnés EA, les fournisseurs CSP ainsi que les clients CSP pour permettre d’afficher leur utilisation actuelle, l’historique de facturation et bien plus encore.

Allez, let’s go, c’est un peu technique, comptez une bonne heure…

Tout d’abord, un peu d’architecture, la solution repose sur 4 composants:

• Data Extraction Service (Azure API)
  • Ensembles distincts d’API REST pour accéder aux informations d’utilisation / de facturation pour chaque type d’abonnement
  • Les API sont exposées via Web Service
• Data Aggregation Engine (Azure Web Job)
  • Azure WebJob est responsable de s’assurer que les données sont collectées à partir de ces API à intervalles réguliers
• Persistent Data Storage (Azure database)
  • Les données sont collectées pour différents types d’abonnements et conservées dans la base de données Azure SQL. Les nouvelles données sont ajoutées automatiquement dans les tables lorsqu’elles sont disponibles tant que le Webjob est en cours d’exécution
• Visualizations and Analytics (Power BI)
  • Des exemples de rapports Power BI, tout simplement

Maintenant, les prérequis:

• 1 souscription Azure bien sûr de type Direct, EA, CSP !
• Azure App Service
• Azure Web Job
• Azure Web API
• Azure SQL Server et sa BDD
• Compte de stockage Azure
• PowerBI Pro (pour les exports de template) et la version Desktop pour uploader les templates
• Visual Studio 2015 with Azure SDK 2.9
• Optionnellement, SQL Management Studio et le support du développement continu DevOPS au travers de VS

Dans l’exemple que je vous montre ici (important), la solution est hébergée hors contexte CSP, c’est à dire que je vais analyser les données des souscriptions CSP dans un autre Tenant Azure.

1. Création des ressources Azure

Créer un Resource group (accès de type « contributeur » à minima), puis créer un compte de stockage

Ensuite, créer la base de données SQL Azure

2. Configuration de l’extraction des données

2.1. Enterprise Agreement

En se connectant au portail https://ea.azure.com/, récupérer les valeurs ci-dessous.

2.2. Cloud Solution Provider

En se connectant au portail https://partnercenter.microsoft.com/, en tant que Global Admin (recommandé de créer un compte spécifique), il faut créer dans le paramètre de compte => App Management une application web et un application native. Attention du bien copier/coller la clé de l’application web générée car elle ne s’affiche qu’une seule fois !

3. Configuration du fichier web.config de la solution

La solution est disponible ici, et l’ouvrira directement dans Visual Studio, sinon voici l’adresse du GITHUB => https://github.com/Microsoft/peek

3.1. Pour les souscriptions EA, renseigner le fichier web.config aux lignes 22 & 23 avec les valeurs relevées aux étapes ci-dessus.

3.2. Pour les souscriptions CSP, renseigner le fichier web.config à partir de la ligne 97:

• The active directory application ID used by the user login, paste your application ID here.
  • ApplicationId = valeur Application Native (step 2 de la capture d’écran)
  • Username/Password = valeur (en clair) de vos identifiants du PartnerCenter
• The active directory application ID used by the application login, paste your application ID here.
  • ApplicationId = valeur Application WEB (step 1 de la capture d’écran)
  • ApplicationSecret = le secret généré (step 1 toujours)
  • Domain = le domaine CSP

Ensuite, reste à publier le tout via Visual Studio ! (un App Service Plan B1 – 1 core, 1.75 Gb RAM – est suffisant, pour SQL un S0 Standard)

A ce stade, le déploiement initial est terminé, on peux le tester via l’URL http://VOTREAPPSERVICE.azurewebsites.net/swagger, ce qui nous donnera ceci comme résultat !

4. Configuration de l’authentification Azure AD

Ceci est nécessaire pour le Webjob qui va crawler les données depuis votre CSP, EA, … pour y injecter les données dans la base de données SQL Azure en se basant sur une authentification Azure AD. Pour cela, il faut aller au niveau de portail Azure dans votre AppService puis dans Authentication/Authorization pour créer une authentification AAD de type Express.

Une fois crée, il faut BIEN noter le ClientID, qui nous sera utile plus tard pour configurer le Webjob.

A ce stade, pour accéder à la page http://VOTREAPPSERVICE.azurewebsites.net/swagger, il va demander de s’authentifier. L’API est donc maintenant sécurisée.

Il faut maintenant récupérer le secret (ou le créer) de l’Application

A nouveau, il faut BIEN noter le secret, qui nous sera utile plus tard pour configurer le Webjob.

5. Configuration du webjob

Dans Visual Studio, dans le webjob, ouvrir le fichier APP.CONFIG et le configure comme détaillé ci-dessous:

Ici, il faut renseigner la configuration de l’application d’authentification Azure AD, crée à l’étape 4 et renseigner le WebApiAADDomainName comme le Tenant hébergeant l’application. Pour rappel, j’ai hébergé cette application en dehors de mon Tenant CSP !

Et ici, il faut renseigner les accès au Partner Center.

Ensuite, vous pouvez modifier:

• la fréquence – ligne 69
• le type de contrat: csp ou csp,ea par exemple – ligne 83
• ligne 93, configurer la date de début voulue, idéalement le début de la signature du contrat CSP
• ligne 94, enlever la date de fin pour toujours obtenir les derniers rapports (mois en cours)
• Vous remarquez qu’il faut à nouveau configurer le compte de stockage – ligne 78 – le backup des data

Et pour finir, publier en tant que WEBJOB depuis VS. Allez dans votre AppService => Webjobs, et le job crée doit apparaître, cliquez sur log pour vérifier que le Webjob va bien chercher les données, si vous obtenez un UNATHORIZED, le fichier de config APP.CONFIG ne doit pas être bon, bien vérifier toutes les étapes!

Maintenant il faut configurer l’AppService pour que celle-ci ne se mette pas en IDLE s’il n’y a pas de trafic.

6. Visualisation & Analytics

Ouf, voici la partie la plus sympa, visualiser et manipuler les données avec PowerBI !

Tout d’abord, s’assurer que Azure SQL se laisse attaquer par votre PC, pour cela, il faut ouvrir le Firewall de SQL Azure vers votre IP ou range IP.

Vous trouverez les templates PowerBI à cette adresse. La version PRO de PowerBI est nécessaire si vous désirez uploader/partager les rapports vers le PowerBI Online. Une fois le rapport ouvert dans PowerBI, il faut changer le string de connexion à la BDD, et voilà ! ça apparaît comme par magie !

Bon, c’est sympa, mais j’ai tous mes clients qui apparaissent dans ces dahsboards…. On va donc pousser la chose un peu plus loin, et créer des vues personnalisées de façon à obtenir des rapports par client. Allez un peu de SQL… Modifier le noms des vues par client ainsi que le nom du client

• CREATE VIEW vCustomerCurrentUsage par le nom du client => vCustomerCurrentUsageMONCLIENT
• [CustomerName] => mettre ici le nom du client (qui apparait dans le CSP, laissez les  »)

CREATE VIEW vCustomerCurrentUsage AS
SELECT [Id]
      ,[Category]
      ,[QuantityUsed]
      ,[ResourceId]
      ,[ResourceName]
      ,[SubCategory]
      ,[TotalCost] * 1.15 as [EstimatedTotalCost]
      ,[Unit]
      ,[CustomerDomain]
      ,[SubscriptionName]
      ,[SubscriptionId]
      ,[SubscriptionStatus]
      ,[BillingStartDate]
      ,[BillingEndDate]
  FROM [dbo].[CspUsageData]
  WHERE
  [CustomerName] = 'demotenant3'

GO

CREATE VIEW vCustomerHistoricUsage AS
SELECT [Id]
      ,[UsageDate]
      ,[SubscriptionId]
      ,[SubscriptionName]
      ,[SubscriptionDescription]
      ,[ServiceName]
      ,[ServiceType]
      ,[ResourceGuid]
      ,[ResourceName]
      ,[Region]
      ,[ConsumedQuantity]
      ,[ChargeStartDate]
      ,[ChargeEndDate]
  FROM [dbo].[CspBillingData]
WHERE [CustomerCompanyName] = 'demotenant3'

GO

CREATE VIEW vCustomerBillingSummary AS
SELECT [Id]
      ,[ChargeEndDate]
      ,[ChargeStartDate]
      ,[ConsumedQuantity]
      ,[Currency]
      ,[PostTaxTotal] * 1.15 as [EstimatedCost]
      ,[Region]
      ,[ResourceGuid]
      ,[ResourceName]
      ,[ServiceName]
      ,[ServiceType]
      ,[Sku]
      ,[SubscriptionDescription]
      ,[SubscriptionId]
      ,[SubscriptionName]
  FROM [dbo].[CspSummaryData]
WHERE 
[CustomerCompanyName] = 'demotenant3'

GO

Le rapport spécifique du client ouvert dans PowerBI, il va falloir éditer la requête. Changer Item par le nom de la vue, par exemple vCustomerCurrentUsageMONCLIENT

Le rapport spécifique à votre utilisateur s’affiche désormais.

Publions le sur PowerBI Online.

 

Et maintenant on va scheduler le rapport pour qu’il récupère les données tous les jours 🙂

Voilà….. Amusez-vous bien !