Contrairement à l'API de TrackTik qui peut suivre toutes les sources de données et les relations les plus récentes parce que les objets dans les réponses peuvent être développés de nombreuses façons 1:1, 1:N, N:N, l'Entrepôt de données est dans un format de table/champs/rangées qui ne supportera pas tous les même relations 1:N ni N:N. C'est au professionnel de l'Informatique décisionnelle de créer ses propres relations, et les nombreuses tables de l'Entrepôt de données ne sont pas mises à jour sans déclencheurs de synchronisation auxquels l'API n'a pas à faire face, mais que l'entrepôt de données doit prendre en charge.

Cela conduit à certaines limites dans ce qui peut être rempli dans les tableaux, et à quelle fréquence (actuellement avec peu de possibilités de cascade/domino à travers des relations complexes).

Les limites sont présentées ci-dessous.

Résumé des points de terminaison et/ou des champs de l'API qui ne peuvent pas être reproduits :

• Points de terminaison qui sont des vues de base de données et non des tables distinctes

• Points de terminaison d'occurrences (de calendrier)

• Champs calculés

• Extensions

• Champs de relations polymorphes

• Listes de relations

La section suivante proposent une analyse plus approfondie de quelques-uns de ces scénarios.

Les entités API qui sont des vues ne peuvent pas être répliquées dans l'Entrepôt de données.

Toutes les tables DWH de TrackTik sont directement connectées à une table sous-jacente au moyen de l'API, de sorte que les événements de création/mise à jour/actions peuvent être directement signalés au service DWH pour le rafraîchissement des données.

Mais certains points de terminaison de l'API sont des vues et ne peuvent donc pas être inclus dans une solution DWH en tant que table. Il n'existe actuellement aucun moyen de détecter les changements d'une vue.

Par exemple, Occurrences de tâches de site Web
Cette entité de données disponible dans l'API fait référence à tous les événements programmés dans le futur en fonction des dates de début et de fin d'un Horaire de tâches de site de client, et des jours de la semaine définis.

Lorsqu'un Horaire de tâches de site de client est modifié, sa table DWH est mise à jour, mais la vue intitulée Occurrences d'horaire de tâches de site de client n'est pas une source de données qui connaît des changements d'état tels que création/mise à jour. Elle ne peut donc pas être incluse, et ne serait jamais mise à jour.

Il existe plusieurs entités de données de ce type qui ne peuvent pas être incluses parce qu'il s'agit d'une vue, par exemple :

• Occurrences contractuels
• Dates des vacances
• Soldes de congés
• Ajustements de la gestion des congés
• Occurrences de la feuille de route mobile
• Occurrences de l'horaire mobile
• Occurrences du calendrier de paie
• Occurrences de tâches du site de client
• Occurrences d'horaire des tours des points de contrôle
• Clients de zone

La documentation de l'API disponible à l'adresse https://<portal domain>/rest/v1 contient des indicateurs qui vous rappellent quelles entités de données ne conviennent pas, et ne peuvent pas être fournies en tant que tables dans la solution de L'entrepôt de données.

Par exemple

Certaines exclusions peuvent se produire sur des champs d'entités API par ailleurs valides, comme avec break-rules et ces champs de conditions et les positions, qui sont des tableaux. La réplication des données ne peut pas représenter un tableau comme une colonne unique dans une table) :

Absence d'événements pour les attributs calculés

Pour que les logiciels de TrackTik fonctionnent en temps réel, il peut y avoir des valeurs de données qui sont calculées en fonction du moment présent, au lieu d'être extraites d'une base de données. Cela permet aux opérations commerciales de fonctionner plus rapidement et dans l'instant, au-delà des délais habituels de persistance des données.

Toutes les valeurs en temps réel qui ne sont pas persistées dans la base de données ne peuvent pas être représentées dans l'entrepôt de données.

Un exemple notable est celui de l'État de la présence au quart de travail.

La minuterie permettant de définir cet état fonctionne en valeurs fixes en fonction de la configuration du portail TrackTik. Si la définition du « retard » est "15 minutes après la date prévue », il peut toujours être nécessaire de considérer l'État de la présence au quart de travail comme étant en retard de 10 minutes, ou de 5 minutes. Bien sûr, vous pouvez réduire le réglage à 5 minutes, mais la situation reste la même pour un retard de 2 minutes ou de 3 minutes. Les champs calculés sont donc utilisés pour la valeur commerciale de la définition du retard et ne sont donc pas des données directement disponibles dans une base de données.

Les Quarts de travail et leurs statuts sont conservés dans la base de données et disponibles dans l'entrepôt de données, mais les taux de rafraîchissement ne seront pas aussi rapides que ceux des champs calculés, de sorte que vous ne pourrez récupérer que les Quarts de travail et les statuts conservés.

Calcul des propriétés qui dépendent des configurations et des références à d'autres tables

Dans l'écosystème TrackTik, il peut y avoir des valeurs qui sont sélectionnées hiérarchiquement par la logique au moment où elles sont récupérées sur la base d'un contexte de limite temporelle, ou d'une opération de l'utilisateur qui s'est produite. Certains de ces pivotements entre une valeur et une autre peuvent impliquer une cascade préemptive de plusieurs opérations de persistance. Les déclencheurs de rafraîchissement des données de l'entrepôt de données sont directement liés, selon une méthode 1:1 par table, aux données persistantes sous-jacentes. Les cascades entre plusieurs tables de données ne sont pas suivies et séquencées dans une file d'attente.

Il peut donc y avoir des situations où une valeur change, sur la base de changements provenant d'autres sources. Tous ces points de données ne seront pas mis à jour ensemble à la fin d'un processus à plusieurs étapes et ne sont donc pas viables pour notre solution d'Entrepôt de données. L'utilisateur de l'entrepôt ne pourrait jamais savoir si une valeur est actuelle, retardée ou si elle n'est pas mise à jour du tout.

L'un de ces exemples est la valeur autonome (en dehors du contexte d'une facture, d'un cycle de paie, etc.) du taux de rémunération d'un employé. Les taux de rémunération peuvent être directement tirés des données ou déduits de plusieurs contextes de données supplémentaires généralement liés à la configuration de l'application Web TrackTik, comme le taux régional par rapport au taux de l'employé, ou d'autres catégories d'employés comme le temps partiel. Lorsqu'un taux est en mouvement ou déterminé hiérarchiquement sur la base de diverses règles commerciales en temps réel, il ne peut pas être pris en compte par l'entrepôt de données.

Par conséquent, les taux de rémunération des salariés ne sont visibles par une solution DWH que lorsqu'ils sont au repos, dans des entités de données telles qu'employment-profiles, billable-items, invoices, payroll-payrun items et ainsi de suite. Ceux-ci sont soit des configurations de base, soit des instantanés générés par programme dans le but de créer un amalgame de diverses valeurs stables et calculées. Cela ne peut se faire que par la logique, et les tables et les lignes de l'Entrepôt de données ne sont pas des logiciels distincts par entité de données.