2010-07-02 21 views
1

J'utilise Navision Dynamics 5.0 et j'ai besoin d'exporter toutes les données financières dans mon datawarehouse régulièrement (1 fois par jour). Et donc je ne veux pas utiliser les fichiers csv comme méthode d'exportation.Exporter des méthodes de Navision Dynamics 5.0 vers des applications de datawarehouse/OLAP?

Quelles autres méthodes sont normalement utilisées? Cela doit être une tâche régulière pour toutes les entreprises qui utilisent Navision Dynamics, et qui a besoin d'extraire les données de manière automatique.

Je suis bien sûr également préoccupé par le verrouillage des tables lors de l'exportation des données.

Je peux penser à ces méthodes jusqu'à présent:

1) Accès ODBC direct à toutes les tables sous-jacentes

2) Création d'une lecture seule vue indexée (vue mateterialized) au-dessus des tables Navision , qui contient une copie des données Navision, puis peut être consulté par le datawarehouse. (NB: Une vue indexée est une vue qui a été matérialisée, c'est-à-dire qu'elle a été calculée et stockée.)

3)?

4)? Laissez-moi vous entendre des façons typiques de faire l'exportation. PS: J'ai entendu dire qu'il n'y a pas d'option d'exportation webservice pour Navision Dynamics 5.0, uniquement dans la version la plus récente de NAV2009. Donc je ne peux pas utiliser une méthode webservice.

Répondre

1

J'ai trouvé ce document qui décrit quelques-unes des différentes méthodes d'exportation: http://nav.dk/files/Nav_IntegrationGuide1.2.pdf

à continuer ma liste, voici quelques autres options:

3) apparaît comme une solution pourrait utiliser Navision propre ODBC pilote appelé NAV ODBC Driver (NODBC)

4) Une autre solution pourrait être d'utiliser les Dataports Navision in-build pour exporter des données. Cependant, Dataports ne peut produire que des fichiers csv.

+0

Le lien vers le document PDF est cassé, s'il vous plaît pouvez-vous résoudre ce problème? Merci/ – Kev

0

Vous pouvez également utiliser XmlPorts si un fichier XML est préférable à csv. DataPorts et XmlPorts vous permettent d'agréger des données: par exemple, vous pouvez exporter les en-têtes des ventes avec les lignes de chaque en-tête, si cela est utile dans votre scénario.

Vous pouvez également utiliser des filtres, ce qui vous permet d'exporter quotidiennement des mises à jour incrémentielles vers l'entrepôt. Si vous êtes préoccupé par le fait de conserver des verrous pendant longtemps, vous pouvez également essayer d'utiliser des filtres pour exporter les données en morceaux. Je crois que la plupart des solutions utilisent le NAS (Navision Application Server) pour planifier l'exécution de DataPorts ou de XmlPorts, de sorte que l'exportation est pilotée par NAV. Comme autre alternative à l'utilisation de NODBC, vous pouvez également explorer en utilisant CFront, qui est une API C/.NET donnant un accès de niveau relativement bas aux données, y compris la possibilité d'évaluer les champs de flux, etc. NODBC et CFront sont vraiment les seulement les options si vous voulez appeler NAV (plutôt que d'utiliser le NAS pour pousser les données comme csv/xml).

Je n'ai pas comparé les performances relatives de chaque méthode, mais je pense que NODBC et CFront seraient les plus rapides pour de gros volumes de données.NODBC, CFront et le NAS requièrent tous des granules spécifiques dans votre licence. Vous pouvez donc vérifier, le cas échéant, quelle licence vous utilisez actuellement.

+0

Quand vous parlez de tenir des verrous pendant longtemps, que voulez-vous dire? Peut-il détruire des données ou est-ce seulement un problème de performance? Si je fais uniquement lire en lecture seule lorsque j'exporte des données, il ne devrait pas y avoir de risque de détruire des choses pour les autres utilisateurs qui écrivent sur les tables? Je devine que je pourrais éprouver des lectures sales (lire des données périmées), mais les opérations d'écriture devraient toujours être possibles pour d'autres? (mais leur performance en écriture pourrait diminuer un peu ou?) – MOLAP