Recherche

Salut la communauté, Le programme des présentations du matin est finalisé ! *************************************** Mardi 21 juin, 9h00 – 12h00 Bienvenue et Présentation Don Woodlock, Head of Healthcare Solutions, InterSystems Succès continu Terry Ragon, CEO, InterSystems Tout mettre en œuvre : perturber les soins de santé Don Woodlock, Head of Healthcare Solutions, InterSystems L'état d'esprit des designers : comment le Design Thinking peut changer notre façon de travailler Jess Kessin, Design Leader, Entrepreneur, Educator Gérer la santé cérébrale à grande échelle : transformer les soins de santé avec l'IA et l'interopérabilité Tom Sawyer, Chief Financial Officer, Cognetivity Connaître et rester simple : offrir une meilleure expérience aux patients et aux prestataires Eduardo Conrado, Executive Vice President, Chief Strategy & Innovation Officer, Ascension InterSystems Healthcare : Quoi de neuf Table ronde animée par Jonathan Teich, MD, Director, HealthShare Product Management, InterSystems *************************************** Mercredi 22 juin, 9h00 – 12h00 Bienvenue au deuxième jour Scott Gnau, Head of Data Platforms, InterSystems Zone to Win : s'organiser pour rivaliser à une époque de perturbations Geoffrey Moore, Bestselling Author, Consultant, Disruptive Technology Specialist Smart Data Fabric : Permettre les innovations futures Scott Gnau, Head of Data Platforms, InterSystems Casser la banque : comment BBTS a intégré les données pour activer l'Open Banking Flávio Augusto Corrêa Basilio, Executive Director & President, BBTS/Banco do Brasil Ne négliger aucun effort : la transformation de SPAR via les données de vente au détail connectées Gerd Karnitschnig, Head of Software Solutions International, SPAR/ASPIAG InterSystems IRIS : Quoi de neuf Panel animé par Jeffrey Fried, Director Product Management, Data Platforms, InterSystems *************************************** Jeudi 23 juin, 9h00 – 12h00 Bienvenue au troisième jour John Paladino, Head of Client Services, InterSystems Améliorations pour des client Joe Lichtenberg, Head of Product & Industry Marketing, Data Platforms, InterSystems Ce que l'IA peut et ne peut pas faire Janelle Shane, AI Speaker & Humorist Passion pour la réussite des clients John Paladino, Head of Client Services, InterSystems L'apprentissage comme pierre angulaire du succès Jim Breen, Head of Learning Services, InterSystems Gagner l'acceptation et l'adoption Modéré par Mike Fuller, Regional Marketing Director, InterSystems L'éclat de la start-up Randy Pallotta, Head of North American Sales Engineering Hackathons : amusants et innovants Dean Andrews Head of Developer Experience Conclusion et remerciements Jim Rose, Head of Global Marketing Des questions? Contactez summit22@intersystems.com

Salut les développeurs ! Voici encore un court message qui a pour but de simplifier la vie des développeurs. Nous allons maintenant vous expliquer comment faire en sorte que GitHub exécute des tests unitaires à chaque poussée vers le référentiel en ajoutant un seul fichier au référentiel. Gratuitement. Dans le nuage de Github. Ça a l'air génial, n'est-ce pas ? C'est possible et très facile à faire. Le mérite revient à @Dmitry.Maslennikov (et [son référentiel](https://github.com/caretdev/globals-tool)), gestionnaire de paquets "ZPM Package Manager", et aux GitHub Actions.  Voyons comment tout cela fonctionne !  Considérons d'abord un référentiel avec des tests, par exemple [le modèle IRIS de base](https://github.com/intersystems-community/intersystems-iris-dev-template).  Supposons également que vous chargez votre code de développement dans le docker IRIS à l'aide de ZPM. Si ce n'est pas le cas, [regardez la video](https://www.youtube.com/watch?v=havPyPbUj1I) sur la façon de le faire.  Dans ce référentiel particulier, il s'agit de [la ligne suivante](http://In%20this%20particular%20repo,%20it%20goes%20with%20the%20following%20line%20and%20with%20the%20presence%20of%20module.xml.) et avec la présence de [module.xml](https://github.com/intersystems-community/intersystems-iris-dev-template/blob/master/module.xml): zpm "load /home/irisowner/irisbuild/ -v":1:1 Ensuite, ajoutons un [scénario de GitHub Actions](https://github.com/intersystems-community/intersystems-iris-dev-template/blob/master/.github/workflows/runtests.yml) qui permettra de construire l'image et d'exécuter les tests : name: unittest on: push: branches: - maître - principale pull_request: branches: - maître - principale version: types: - libéré tâches: build: runs-on: ubuntu-latest étapes: - utilisations: actions/checkout@v2 - nom: Build and Test utilisations: docker/build-push-action@v2 avec: contexte: . push: faux charge: vrai balises: ${{ github.repository }}:${{ github.sha }} build-args: TESTS=1 Ce scénario construit une image docker en utilisant [Dockerfile](https://github.com/intersystems-community/intersystems-iris-dev-template/blob/master/Dockerfile) du référentiel à chaque **push** ou **pull-request** vers la branche **master** ou **main**. Voici une [ligne supplémentaire](https://github.com/intersystems-community/intersystems-iris-dev-template/blob/e7e25e67400deca1b01c26fbadd421b0bc1e2491/.github/workflows/runtests.yml#L28) qui transfère la variable TESTS=1 au Dockerfile : build-args: TESTS=1 Cet argument [est évaué](https://github.com/intersystems-community/intersystems-iris-dev-template/blob/e7e25e67400deca1b01c26fbadd421b0bc1e2491/Dockerfile#L16) dans le Dockerfile et si TESTS=1, il exécute les tests du paquet zpm du référentiel :     ([ $TESTS -eq 0 ] || iris session iris -U $NAMESPACE "##class(%ZPM.PackageManager).Shell(\"test $MODULE -v -only\",1,1)") && \ Cette ligne vérifie le paramètre $TESTS et s'il n'est pas égal à 0, elle ouvre la session iris dans $NAMESPACE (IRISAPP dans ce cas) et exécute la commande ZPM : test $MODULE -v -only L'indicateur -only exécute uniquement le test sans charger le module (car il a été chargé auparavant dans le scénario de construction de docker). Le nom du module [est défini](https://github.com/intersystems-community/intersystems-iris-dev-template/blob/e7e25e67400deca1b01c26fbadd421b0bc1e2491/Dockerfile#L10) via $MODULE="dc-sample-template" dans ce cas : ARG MODULE="dc-sample-template" La commande va exécuter tous les unittests que nous avons mentionnés dans le module ZPM. Dans ce cas, nous le présentons avec [cette ligne](https://github.com/intersystems-community/intersystems-iris-dev-template/blob/e7e25e67400deca1b01c26fbadd421b0bc1e2491/module.xml#L11): <UnitTest Name="/tests" Package="dc.sample.unittests" Phase="test"/> ce qui signifie que les tests unitaires sont situés dans le dossier /tests du référentiel et que la ressource est dc.sample.unittests [paquet de classe](https://github.com/intersystems-community/intersystems-iris-dev-template/tree/master/tests/dc/sample/unittests) qui a deux classes. Ce scénario va construire l'image de votre dépôt sur le nuage GitHub et exécuter des tests pour chaque push ou pull request vers la branche maître ! Voyons comment cela fonctionne ! [La méthode Test42](https://github.com/intersystems-community/intersystems-iris-dev-template/blob/e7e25e67400deca1b01c26fbadd421b0bc1e2491/tests/dc/sample/unittests/TestObjectScript.cls#L4) prévoit que la méthode dc.sample.ObjectScript).Test() renvoie 42. Changeons la ligne en 43 et envoyons [pull-request](https://github.com/intersystems-community/intersystems-iris-dev-template/pull/10/checks). Nous pouvons voir (dans la section [Actions](https://github.com/intersystems-community/intersystems-iris-dev-template/actions) ) que la pull-request a initié l'action Github. En effet, la construction a échoué :  Et les détails de la phase indiquent que Test42() a échoué sur AssertEquals 42 =43 :  Github envoie également des notifications par courriel en cas d'échec des constructions CI. Remarque : pour exécuter les tests localement, il suffit d'appeler : USER>zpm test "module-name" Et si nous remettons la valeur de la variable à 42, les tests seront OK !  Et s'il s'agit de Pull-Request, vous pouvez voir le résultat de l'IC dans la section spéciale de contrôle [Checks](https://github.com/intersystems-community/intersystems-iris-dev-template/pull/11/checks):  Et voilà ! Pour résumer, faire fonctionner GitHub (gratuitement !) pour les constructions de dockers et les unittests des projets InterSystems IRIS sur les pushes ou les pull-requests nécessite un scénario [CI Github Actions scenario](https://github.com/intersystems-community/intersystems-iris-dev-template/blob/master/.github/workflows/runtests.yml), qui sera le même pour chaque projet, et trois lignes dans le Dockerfile : [Le nom ZPM $MODULE](https://github.com/intersystems-community/intersystems-iris-dev-template/blob/6b7c21817326ecf9370cc8ec54b9751f7e977ad7/Dockerfile#L10) - ceci doit être mis à jour avec chaque projet, [Le paramètre $TEST](https://github.com/intersystems-community/intersystems-iris-dev-template/blob/6b7c21817326ecf9370cc8ec54b9751f7e977ad7/Dockerfile#L9), [et la ligne RUN TEST.](https://github.com/intersystems-community/intersystems-iris-dev-template/blob/6b7c21817326ecf9370cc8ec54b9751f7e977ad7/Dockerfile#L16) Et utilisez le gestionnaire [ZPM Package Manager](https://openexchange.intersystems.com/package/ObjectScript-Package-Manager)! Les commentaires et les réactions sont les bienvenus, et bon codage ! _L'image du titre est liée à l'histoire de l'un de mes auteurs de SF préférés, Robert Sheckley, ["Quelque chose pour rien"] (https://en.wikipedia.org/wiki/Something_for_Nothing_(book)) - la voici en [audio aussi] (https://www.youtube.com/watch?v=CL0GQTtx-5A), profitez-en !_    

Salut la Communauté! Regardez cette vidéo pour savoir comment vous pouvez projeter des données FHIR vers SQL pour faciliter l’exploitation des données et le reporting : Intervenant: @Guillaume.Rongier7183, Évangéliste Technologique, InterSystems N'hésitez pas à vous abonner à la chaîne InterSystems France sur YouTube !

InterSystems a corrigé un défaut pouvant entraîner une instabilité du client ECP (Enterprise Cache Protocol) dans de rares cas. Le défaut existe dans les produits suivants et dans toutes les offres InterSystems basées sur ceux-ci. Les versions concernées sont 2022.1.x, 2022.2 et 2022.3 : InterSystems IRIS® InterSystems IRIS for Health™ HealthShare® Connexion Santé La version concernée est 2022.2 (uniquement pour les clients déployant ECP) : InterSystems HealthShare® Le problème ne peut se produire que sur les systèmes clients ECP. Lorsque ce problème est déclenché, les processus peuvent rencontrer une erreur <SYSTEM> ou <DATABASE>. Suite à l'erreur, le client ECP subit une instabilité ; dans certains cas, l'instance peut se bloquer. Il n'y a aucun impact sur les données et le serveur de données ECP n'est pas affecté. Pour éliminer l'instabilité, vous devez redémarrer l'instance client ECP. Si vous avez une instance affectée d'IRIS, IRIS for Health ou Health Connect, la correction consiste à effectuer une mise à niveau vers la version 2023.1 ou 2022.1.3, qui seront toutes deux publiées sous peu. Si vous avez une instance de HealthShare impactée, un ensemble séparé de documentation d'alerte avec des recommandations de correction sera publié sous peu. La correction du défaut est identifiée comme TR1162 et sera incluse dans toutes les futures versions d'InterSystems IRIS®, InterSystems IRIS for Health™ et HealthShare® Health Connect ainsi que tous les produits InterSystems basés sur eux. La correction est également disponible via la distribution ad hoc. Si vous avez des questions concernant cette alerte, veuillez contacter le Worldwide Response Center.