En offrant un support natif pour toutes les architectures (x86, ARM, Power...), NTi ouvre de nouvelles possibilités entre l'IBM i et les systèmes embarqués/temps-réel.
Les opérations sur site exigent un accès immédiat aux données métier. Selon le contexte, l’action peut déclencher des traitements ou des règles portées par des programmes IBM i, depuis des terminaux mobiles ou embarqués.
Mise à jour des stocks en temps réel
Gestion des entrepôts en mobilité
Consultation des équipements sur site
Collecte des données d’inspection
Avec NTi, l’application .NET s’exécute localement sur le terminal et accède nativement aux ressources IBM i. Vous réduisez la surface d’exposition (pas de service applicatif supplémentaire à publier) et vous gardez le contrôle via les mécanismes IBM i (profils, droits, audit).
Saisie immédiate
Données capturées à la source
Accès DB2 for i, programmes RPG/CLP/36, commandes CL
Un exemple concret d’usage embarqué
Scanner un code-barres ou un QR code
Voir la documentation
using var conn = new NTiConnection(connString);
conn.Open();
conn.Execute("INSERT INTO
SAMPLE.BARCODES (SCANDATE, SCANTYPE, VALUE)
VALUES (@Time, @Type, @Value)",
new
{
Time = DateTime.Now,
Type = scan.Format.ToString(),
Value = scan.Value,
}
);
Insertion SQL avec NTi côté .NET
Confirmation utilisateur instantanée
GESTION DE DONNEES D'UN FICHIER
Format . . . . : SCAN
*RECNBR: 9
SCANDATE: 2024-04-04-16.55.26.903886
SCANTYPE: EAN8
--------------------------------------------
VALUE: 26061160
Donnée enregistrée sur IBM i (DB2 for i)
Supprimez les coupures entre l’action et le traitement avec .NET et NTi, et maîtrisez précisément les données à transmettre vers l’IBM i.
Un même accès IBM i avec NTi, mais décliné selon le réseau, la sécurité et le volume de terminaux.
Actions qui doivent être traitées immédiatement: scan, validation, consultation ou mise à jour métier.
NTi s’exécute dans l’application .NET, directement sur l’appareil.
L’application consomme directement les ressources IBM i (données ou programmes métiers déjà en place), sans couche intermédiaire.
Beaucoup de terminaux sur un même site, ou besoin de verrouiller l’accès réseau.
On centralise les échanges via une passerelle .NET locale au lieu de connecter chaque appareil directement à l’IBM i.
NTi s’exécute dans la passerelle locale développée en .NET. C’est l’unique composant qui accède aux ressources IBM i.
Réseau instable ou absent (mobilité, zones blanches, bâtiments difficiles). L’opérateur doit pouvoir continuer à travailler sans bloquer.
L’application enregistre les actions localement. Lors de la synchronisation, NTi est utilisé pour transmettre ces actions vers l’IBM i, mettre à jour les données et déclencher la logique métier existante si nécessaire.
Avec NTi, exploitez directement depuis vos applications .NET les programmes RPG, règles de gestion et données existantes.
Applications embarquées, services intermédiaires et outils d'exploitation, tout repose sur .NET.
NTi s’appuie sur les mécanismes natifs de l’IBM i: profils, autorités et journalisation. Vous gardez la maîtrise de quand et comment l’IBM i est sollicité.
Optimisé pour absorber les pics d'activité: latence réduite, connexions réutilisées, et corrélation claire entre connexions .NET et jobs IBM i.
Profitez de 30 jours d’essai pour mettre NTi à l’épreuve
Ici, l’IoT et l’edge-computing correspondent à des usages réalisés au plus près de l’action : scan de codes-barres, saisie terrain, contrôle qualité, suivi d’équipements ou relevés techniques...
Ces usages doivent pouvoir interagir avec l’IBM i immédiatement, sans passer par un service cloud, une API distante ou une plateforme de collecte intermédiaire avant qu’un traitement métier ne soit exécuté.
Aujourd'hui, l'une des solutions consiste à s'appuyer sur .NET et NTi pour s'affranchir des contraintes techniques classiques.
Les applications accèdent directement aux données IBM i et déclenchent les traitements métiers existants nécessaires.
Quand les actions doivent être traitées immédiatement, la latence réseau et la disponibilité des services distants deviennent des contraintes structurantes.
Exécuter l’application localement permet de traiter l’action au moment où elle se produit, indépendamment des aléas réseau, tout en garantissant des temps de réponse constants.
L’accès à l’IBM i intervient uniquement lorsque c’est nécessaire pour déclencher un traitement métier ou enregistrer une information structurante, sans dépendre d’une infrastructure distante pour chaque interaction.
Non. Les applications .NET exécutées en périphérie jouent un rôle de filtrage et d'orchestration. Elles déterminent quand un traitement métier doit être déclenché sur l’IBM i.
Cela évite de solliciter le système pour chaque action (scan, saisie, mesure...) tout en conservant l'IBM i comme système central pour les données et la logique métier.
Ce comportement relève de la conception applicative : c’est l’application .NET qui définit quand et comment l’IBM i est sollicité, en fonction des règles métier et des choix de conception portés par les équipes de développement.
.NET fournit un cadre applicatif unique et complet pour concevoir l'ensemble des applications métier nécessaires au système d'information.
L'edge-computing et l'IoT peuvent être développés en .NET, avec les mêmes outils et les mêmes pratiques, sans ajouter de technologie spécifique.
Avec NTi, ces applications accèdent instantanément aux ressources IBM i, base de données DB2 for i, programmes RPG, CLP, 36, commandes CL sans dupliquer la logique métier.
Elle évite d'introduire une couche supplémentaire entre les applications et l'IBM i.
Les applications .NET portent l’interface, la logique d’orchestration et les usages déportés.
L’IBM i conserve la responsabilité des données et des règles métier existantes.
NTi matérialise cette frontière en permettant aux applications .NET d’invoquer directement les ressources IBM i, sans exposer le système sous forme d’API et sans déplacer la logique métier hors de son périmètre naturel.
