SilverDev est un système complet permettant de faire du développement graphique en RPG Ile. Il comprend un serveur de communication en tcp/ip, un "client riche" pour le lancement des applications, et les outils de développement (conception des fenêtres graphiques, programmes de service pour la programmation en RPG, outils de gestion des applications et des travaux ...).
SilverDev permet de réaliser et exécuter des applications au "look and feel" Windows sans avoir la complexité du Client/Serveur.
Tous les "objets" créés lors de la réalisation d'une application sont stockés sur l'AS/400, évitant les problèmes de déploiement. Les applications sont immédiatement disponibles pour les utilisateurs, comme avec les développements en 5250.
Les programmes sont exécutés entièrement sur l'AS/400, garantissant ainsi une plus grande stabilité, et une maintenance facilitée.
L'utilisation du RPG pour le développement, permet ainsi de maîtriser plus vite le produit (pas de nouveau langage à apprendre) et de réaliser rapidement les premières applications graphiques.

Non, SilverDev utilise son propre serveur de communication en TCP/IP, et ne nécessite aucun autre serveur tels que Apache, WebSphere AS, …

Oui, SilverDev utilisant tcp/ip, il est utilisable, tant pour le développement que pour l’exécution au travers de l’internet. La seule spécificité est que en configuration de base, SilverDev utilise le port 7003 qui n’est pas toujours « ouvert » dans les systèmes de protection (Firewall, routeurs, …). Il suffit simplement soit de modifier le port utilisé part SilverDev lors de son démarrage (StrSvd) soit d’ouvrir ce port sur les firewall, routeurs …
Silverdev intègre de puissantes fonctions de "cache" et d'optimisation/compression des trames échangées. Ainsi la bande passante utilisée est similaire, voire inférieure au 5250 à traitement égal.
Son utilisation pour des sites distants (Agences, filiales ...) est trés simple et remarquablement performante (bien meilleure que des pages Web)

Cela est possible en utilisant des outils de type GO Global (de GraphOn) qui permettent trés simplement d'executer des applications Windows à distance, sur des postes Linux, MacIntosh (!), ou des au travers de browser en Java ou Javascript.

Non, les programmes écrits pour SilverDev utilisent directement l’interface graphique. Il n’est même pas possible d’utiliser des programmes 5250 dans une application SilverDev.

NON, à condition d’avoir un réseau tcp/ip reliant l’AS400 aux postes clients (micros) et de disposer de la place disque nécessaire à l’installation du produit (seulement 30 Mo !) ce qui est généralement le cas !

Le droit d'utilisation de licence de SilverDev est facturé par AS/400, le tarif étant fonction du groupe de facturation (P05, P10, ...). Avec une licence SilverDev sur un AS400, vous pouvez utiliser le produit pour autant d'utilisateurs et de développeurs que vous le désirez ! Si vous avez besoin de licences supplémentaires (plusieurs AS400), une tarification dégressive très avantageuse est prévue.
NOUVEAU : La licence SilverDev est également disponible en fonction du nombre de développeurs et d'utilisateurs. Cette possibilité permet de réaliser des applications SilverDev à moindre coût.
Contactez nous pour plus de précisions.

Les compétences classiques d’un développeur RPG sur AS400 sont suffisantes. Les applications écrites pour SilverDev différent peu de celles écrites pour le 5250, cependant les programmes sont en RPG IV Ile. Des connaissances d’outils de développement sous windows (VB, Access, Delphi, …) sont un atout mais ne sont pas indispensables.
La formation SilverDev permet de maîtriser la conception de l’interface graphique à l’aide de composants, propriétés et évènements.

Les applications SilverDev fonctionnant dans des "jobs batch", tout ce qui peut être fait dans ces travaux peut l'être en SilverDev. Il est ainsi possible de réutiliser toute la BdD, les programmes ILE ou non, les data area,... mais également de soumettre d'autres travaux. Seuls les programmes utilisant des écrans (DSPF ou PNLGRP) ne peuvent être utilisés directement. Ils devront être réécrits, tout en ayant la possibilité de réutiliser des parties importantes du code d'origine (contrôles, accès Bdd, calculs ...)

OUI. Il est plus rapide développer en SilverDev qu'en 5250 classique du fait de la programmation évenementielle. Le développeur doit mettre beaucoup moins de choses en oeuvre pour gérer l'interface. Le 5250 impose au programmeur d'écrire le code (instructions) nécessaire à la gestion des "évenements" de l'interface (touches fonctions ...), alors qu'avec SilverDev cela est pris en charge automatiquement.

SilverDev permet de travailler à 2 niveaux. Soit un niveau de base similaire au développement en 5250, soit à un niveau supérieur par l'utilisation du générateur intégré, permettant d'améliorer la productivité.

L'utilisation du RPG IV comme langage de programmation permet également des développements rapides par la possibilité de réutiliser des parties de "code" déjà écrites (F15+ Copie dans PDM SEU ...)

Un programme RPG Ile est un programme SilverDev tout simplement par son utilisation de fonctions mises à disposition par un service programme (SDSRVPGM). Le principe est exactement le même que celui des APIs IBM utilisable en Ile via des services programmes.

Oui, et c’est sûrement l’un des points les plus innovants de SilverDev. La programmation en SilverDev utilise pleinement les principes de la programmation évènementielle habituellement réservée aux outils micros. Ceci est tellement vrai que ça peut-être déroutant au début pour un programmeur AS/400 habitué uniquement à la programmation procédurale. En effet en programmation AS/400 classique, quand un programme interactif (avec un fichier écran) appelle un autre programme interactif (avec son propre fichier écran), l’exécution est suspendue jusqu’à la fin de l’exécution du programme appelé.
En programmation évènementielle, et donc avec SilverDev, le comportement est différent : les deux programmes sont « actifs » en même temps : les fenêtres des deux programmes réagissent aux évènements de l’utilisateur ! (cela peut-être bien entendu bloqué par le programmeur).
La souplesse et la richesse de l’interface sont bien celles d’une interface graphique Windows classique contrairement aux outils de revamping classiques qui sont liés aux contraintes de l’interface 5250 sous-jacente.

Quand vous créez l’interface graphique (les « fiches ») avec SilverDev, vous indiquez les évènements auxquels votre programme va « réagir ». Dés que la fiche est affichée, votre programme est en « sommeil » (pas de consommation de ressources). Ce n'est qu’au déclenchement par l’utilisateur d’un évènement (clique de souris, touche fonction, timer …) que la partie « cliente » de SilverDev sur le micro signale ,via Tcp/ip, cet événement au serveur SilverDev sur l’AS/400. Ceci à pour effet de lancer l’exécution de la procédure prévue par votre programme pour gérer cet événement. A la fin de la procédure, le contrôle retourne automatiquement à la fiche sur le micro pour attendre un autre événement.

Non, bien qu’il soit difficile de comparer des choses aussi différentes. Certaines fonctions peuvent prendre plus de ressources, mais cela est le plus largement compensé du fait de l’utilisation d’une interface plus riche que le 5250 et donc nécessitant moins de traitement dans les programmes sur l’AS400 : plus de contrôles côté interface, moins de changement de formats, gestion de la cinématique par le programme très allégée par l’orientation « évènementiel », … Il est évident que demander l’affichage d’une image (par exemple) est consommatrice de ressources (minimes) pour accéder au fichier « stream » sur l’IFS, puis pour le transmettre au poste client. Mais ceci ne peut-être mis en parallèle avec une interface 5250 ignorant les images. Si l’on compare avec les outils de revamping, la consommation de ressources est nettement inférieure car ceux-ci ajoutent leur propre consommation à celle de l’application 5250.

De plus, et contrairement aux systèmes basés sur l'utilisation du web (http), les principes de l'interface SilverDev sont similaires à ceux du 5250. L'interface ("fiches") est "compilée" pour une transmission et une exécution trés rapides. Ensuite, seules les modifications de propriétés et les déclenchements d'évènements transitent entre le poste client et le programme sur l'AS/400, minimisant les ressources réseau et processeur nécessaires.

De nombreuses fonctionnalités sont prises en charges par les "composants" sur le poste client, diminuant de fait les traitements effectués côté serveur (exemple tri des colonnes de "sous-fichiers")

A partir de la version 1.20, la fonction de "cache" et la compression (plus diverses optimisations) diminuent de prés de 80 % les flux échangés. On arrive ainsi à un volume de données échangées similaire voire inférieur au 5250

Il est logique qu’un produit aussi innovant que SilverDev suscite des interrogations, voire des doutes. Tout d’abord, SilverDev est simple car il a été conçu pour être simple. Notre objectif constant a été de faire un outil de développement permettant une productivité au moins aussi grande que celle que l’on obtient en développement classique (pour des applications de gestion).
SilverDev est réellement simple car il réutilise le meilleur de deux « mondes » : Windows et l’AS400. Grâce à la convivialité de l’interface graphique sous windows, il est simple, voire ludique, de concevoir des interfaces graphiques.
Grâce à la puissance et l’orientation gestion du RPG et la BdD de l’AS400, la programmation est simple, stable, efficace et hautement productive.

De nombreux facteurs entrent en ligne de compte.
Du côté technique, il fallait que certaines conditions soient réunies : la possibilité de créer dynamiquement et rapidement des fiches sur un micro, la généralisation des réseaux (lan), une couche de communication rapide, stable et largement répandue (c’est maintenant le cas avec tcp/ip), et surtout un langage de programmation côté AS permettant de gérer les évènements (ce qui est le cas avec RPG IV ile).
Il y a certainement un facteur psychologique important qui a longtemps bloqué les esprits. L’idée est encore aujourd’hui largement répandue que « l’AS/400 n’est pas une plate-forme permettant de faire simplement des applications graphiques, donc cela ne peut-être possible ! Sinon cela se saurait !» . Il suffit parfois de sortir du « cadre de référence » et d’assembler les bonnes pièces du puzzle. Car, sans trahir de secret, SilverDev n’utilise aucune technologie complexe ou nouvelle. Il n’est que l’assemblage judicieux de plusieurs techniques et idées pour en faire une innovation majeure.
Peut-être également y-a-t-il un aspect « psycho-commercial » basé sur le sacro-saint : « pourquoi faire simple quand on peut faire compliqué ? »…
… surtout si le compliqué se vend bien … et cher !

Pas exactement. L’orientation de SilverDev a volontairement été faite sur le développement d’applications de gestion. Ce qui est la base de la conception de l’AS400.
Ainsi, certaines facultés des composants graphiques ont été « bloquées » d’une part pour simplifier la compréhension et l’utilisation du produit, et d’autre part pour éviter de dégrader les performances par l’utilisation de fonctions très consommatrices de ressources et sans grand intérêt pour les applications de gestion.
Il est donc clair qu’il ne sera pas possible avec SilverDev de faire des applications hautement interactives et graphiques tels que des jeux d’arcade ! mais encore une fois, ce n’est pas notre objectif. Cependant, les technologies sous-jacentes utilisées nous permettront dans l’avenir d’ouvrir de plus en plus ces fonctions verrouillées au fur et à mesure de l’évolution des puissances des materiels et des réseaux.
A l’opposé, les concepts de SilverDev permettent de faire facilement et de façon stable des choses complexes en programmation micro. Tout simplement car les programmes sont sur l’AS400.

Comme tous les travaux de serveurs de communication sur l’AS400 (http, odbc, …) les noms des travaux sont « génériques » et il est souvent difficile d’identifier un travail précis. Cependant, SilverDev prévoit une commande AS400 : WRKSDJOB, permettant d’afficher les travaux de Silverdev avec affichage de l’utilisateur réel (« en cours »), la commande de démarrage de l’application, … Il est ainsi aisé de faire la maintenance des applications SilverDev (visualisation et gestion des travaux, démarrage de la maintenance du travail, …)

Les programmes SilverDev fonctionnant en mode batch, il faut préalablement mettre le travail en question en mode maintenance par la commande STRSRVJOB. Pour aider le développeur à retrouver le travail, SilverDev fournit la commande WRKSDJOB d’affichage et gestion des travaux SilverDev. Il suffit ensuite d’utiliser les commande classiques de déboguage (STRDBG, STRISDB …)

Oui, les programmes SilverDev s'executant en mode batch, ils ne nécessitent aucune puissance CPW interactive, permettant ainsi des économies substantielles. De même, sur les machines ayant des CPW interactifs mais en moindre quantité que pour le batch, c'est toute la puissance de la machine qui est disponible.

Bien entendu. Le développement de l'interface graphique se fait au travers du serveur SilverDev fonctionnant en mode Batch. En ce qui concerne l'écriture des programmes RPG IV, cela est possible sans SEU à l'aide des outils fournis par IBM (Code/400, Eclipse) ou des fournisseurs tiers. La gestion du serveur proprement dit peut se faire au travers d'iSeries Navigator.

La partie cliente de SilverDev installée sur chaque poste utilisateur, fournit un programme appelé "MyDesk" qui est un "bureau virtuel" graphique des applications SilverDev. Ce bureau virtuel, à l'image du bureau de Windows, contient des icônes representants les applications et permettant de les exécuter par double-clique. Il est également possible d'organiser les applications dans des dossiers et sous-dossiers.
Les informations de ce bureau virtuel (MyDesk) ne sont pas stockées sur le poste du client, mais sur l'AS/400. Ainsi quand un utilisateur se connecte avec son profil à partir d'un autre poste, il aura les mêmes informations. Exactement comme avec les terminaux passifs.
De plus les applications affichées dans le bureau virtuel, sont fonctions des droits de l'utilisateur.

Non, pas nécessairement. Le bureau virtuel doit être installé sur le poste client pour permettre de configurer les informations de connection, mais il est possible de créer des liens sur le bureau Windows vers les applications SilverDev. L'utilisateur n'aura qu'à cliquer sur ces icônes sur son bureau Windows pour lancer l'application SilverDev. Dans un tel cas de figure, l'utilisateur oublie complètement qu'il lance une application sur un AS/400.