Nova postagem

Pesquisar

Discussão (0)1
Entre ou crie uma conta para continuar
Artigo
· Mar. 17 3min de leitura

Un aperçu du Dynamic SQL et Embedded SQL

   

 

 

Contrairement au film mentionné dans l'image (pour ceux qui ne connaissent pas, Matrix, 1999), le choix entre Dynamic SQL et Embedded SQL n'est pas un choix entre réalité et fantaisie, mais une décision à prendre. Ci-dessous, je vais essayer de vous faciliter la tâche.

Si votre besoin concerne les interactions entre le client et l'application (et par conséquent la base de données), le Dynamic SQL peut être plus approprié, car il s'adapte très facilement à ces changements de requête. Cependant, ce dynamisme a un coût : à chaque nouvelle requête, elle est remodelée, ce qui peut entraîner un coût d'exécution plus élevé. Voici un exemple simple d'extrait de code Python.

Exemple de Dynamic SQL 

Sur la base des informations ci-dessus, Embedded SQL est-il le meilleur choix ? Cela dépend. Si on considère uniquement l'agilité d'exécution, on pourrait opter pour cette option. Les instructions SQL sont insérées directement dans le code de programmation, à l'aide de variables HOST pour l'entrée et la sortie des données. L'objectif n'est pas d'enseigner l'utilisation de telle ou telle option, mais plutôt de vous ouvrir aux possibilités et d'en apprendre un peu plus sur chacune.

Voici quelques fonctionnalités pertinentes à prendre en compte lors du démarrage d'un développement nécessitant une requête SQL :

Comme mentionné précédemment, Embedded SQL est souvent reconnu pour ses performances, mais il ne s'agit pas d'une course, et la vitesse n'est pas notre seule préoccupation. Son intégration avec plusieurs langages de haut niveau permet aux développeurs d'optimiser l'utilisation des ressources, car ils n'ont pas besoin de rechercher autant de fichiers externes ou de scripts distincts, ce qui rend le code plus propre et plus facile à maintenir.

Il se distingue également par sa cohérence : les modifications apportées à la base de données peuvent être répercutées dans le code SQL, évitant ainsi d'éventuelles incohérences. Enfin, l'intégration des requêtes au code renforce la sécurité, car les contrôles d'accès peuvent être implémentés directement dans l'application, évitant ainsi les accès non autorisés et les requêtes inappropriées.

Voici maintenant ce que prend en charge Dynamic SQL. Ce dynamisme se manifeste par sa flexibilité : tout est mis en forme au fur et à mesure, requêtes, conditions et même noms de tables ou de champs, au bénéfice du client, l'utilisateur. Il se distingue également par sa simplicité d'administration, car les administrateurs de bases de données peuvent effectuer la maintenance des données et des bases de données, en vérifiant l'impact en temps réel, évitant ainsi les problèmes de compilation majeurs.

En résumé, avec un peu de théorie et un peu de « pratique », toutes ces informations montrent qu'il n'y a pas de bon ou de mauvais camp, ni même de méchant ou de gentil. Le fait est que la connaissance de ce qui sera développé, une analyse approfondie des besoins, mènera à un choix…

De quel côté de la force serez-vous ?

Discussão (0)1
Entre ou crie uma conta para continuar
Artigo
· Mar. 17 3min de leitura

Having trouble connecting your Visual Studio Code to your IRIS instance via WebGateway? Here are some tips!

As you may know, the so-called Private Web Server that came with every IRIS installation has been eliminated, making an external web server necessary.

For Docker deployments, it's most common to use the webgateway image (available here) along with the IRIS image to seamlessly access the management portal. This image can be configured to access via HTTPS without any issues by configuring the certificates.

Problem 1: Unable to verify the first certificate

Your SSL connection through the web gateway may have a self-signed certificate configured, and Visual Studio Code is attempting to verify it. Well, let's remove that verification:

By accessing the Settings menu  and searching for http, you'll find the Proxy Strict SSL  option . Uncheck it to prevent it from attempting to validate the certificate. In Proxy Support, select Off .

Problem 2: /api/atelier web application not found

You may be wondering what Atelier is...well, it's very simple, it was the old InterSystems development environment based on Eclipse and it has become a bit of a "legacy" in the IRIS configuration.

This shouldn't be very common, but it's caused by the /api/atelier web application being disabled. To do this, go directly to the management portal and search for the web application administration screen. From the  Administration > Security > Applications > Web Applications  menu , search for /api/atelier.

Indeed, the app is not enabled. To change this, go to its settings by clicking on its name, then select Enabled App.

With that activation the problem should be solved.

Problem 3: Server unavailable

After configuring everything the server is still not accessible, displaying a message like this:

Most likely, the WebGateway has CSPSystems configured as the access user for your IRIS instance, which appears by default with the name LOCAL. To access the WebGateway console, you can do so from the Management Portal ( Administration > Configuration > Web Gateway Management ) or directly through the URL (https://WEBGATEWAY_IP:WEBGATEWAY_PORT/csp/bin/Systems/Module.cxw). Remember that the access user is CSPSystem  (with the password specified during installation).

The first screen we will see will be the following:

From here we must access Server Access  which will show you the following screen:

As you can see, we only have one server configured, labeled LOCAL, which allows us to directly access the Management Portal (in my case, with the URL  https://localhost/csp/sys/%25CSP.Portal.Home.zen ). Let's look at the configuration:

Indeed, the configured user is CSPSystem and our Visual Studio Code configuration uses superuser to access, let's change the configuration to use superuser and see what happens:

Bingo! Problem solved. We're now connected to our IRIS from the Visual Studio Code WebGateway.

I hope you find it useful.

2 Comments
Discussão (2)2
Entre ou crie uma conta para continuar
Artigo
· Mar. 17 3min de leitura

¿Problemas conectando tu Visual Studio Code con tu instancia de IRIS a través del WebGateway? ¡Pues aquí tienes unos consejos!

Como bien sabréis se ha procedido a eliminar el denominado Private Web Server que venía con cada instalación de IRIS, lo que hace necesario un servidor web externo.

En el caso de los despliegues en docker lo más común es hacer uso de la imagen webgateway (disponible aquí) junto con la de IRIS para poder acceder sin problemas al portal de gestión. Esta imagen se puede configurar para acceder vía HTTPS sin ningún problema configurando los certificados.

Problema 1: Unable to verify the first certificate

Posiblemente tu conexión SSL mediante el webgateway tiene configurado un certificado autofirmado y Visual Studio Code intenta verificarlo. Pues bien, quitemos dicha verificación:

Accediendo al menú de Settings y buscando por http encontraremos la opción Proxy Strict SSL, pues bien, desmarquémosla para que no intente validar el certificado. En Proxy Support seleccionaremos off.

Problema 2: /api/atelier web application not found

Os preguntareis que es eso de Atelier...pues muy sencillo, era el antiguo entorno de desarrollo de InterSystems basado en Eclipse y que ha quedado un poco..."legacy" en la configuración de IRIS.

Este a priori no debería ser muy común, pero es producido porque la aplicación web /api/atelier se encuentra deshabilitada. Para ello accederemos directamente al portal de gestión y buscamos la pantalla de administración de aplicaciones web desde el menú Administración > Seguridad > Aplicaciones > Aplicaciones Web buscamos /api/atelier

Efectivamente, la aplicación no está habilitada. Para modificarlo entramos en su configuración pulsando sobre el nombre y a continuación sólo tenemos que marcarla como Aplicación habilitada.

Con esa activación el problema debería quedar resuelto.

Problema 3: Servidor no disponible

Después de configurar todo el servidor sigue sin estar accesible mostrando un mensaje tal que así:

Lo más problable es que el WebGateway tenga configurado CSPSystems como el usuario de acceso a tu instancia de IRIS que por defecto aparece con el nombre de LOCAL. Para acceder a la consola del WebGateway lo puedes hacer desde el Portal de Gestión (Administración > Configuración > Gestión del Web Gateway) o bien directamente por la URL (https://IP_DEL_WEBGATEWAY:PUERTO_DEL_WEBGATEWAY/csp/bin/Systems/Module.cxw). Recordad que el usuario para acceder es CSPSystem (con la contraseña que se especificó durante la instalación).

La primera pantalla que veremos será la siguiente:

Desde aquí deberemos acceder a Server Access que os mostrará la siguiente pantalla:

Como veis únicamente tenemos configurado un servidor etiquetado como LOCAL que es el que nos permite acceder directamente al Portal de Gestión (en mi caso con la URL https://localhost/csp/sys/%25CSP.Portal.Home.zen). Veamos la configuración:

En efecto, el usuario configurado es CSPSystem y nuestra configuración de Visual Studio Code utiliza superuser para acceder, cambiemos la configuración para que haga uso de superuser y veamos que sucede:

¡Bingo! Problema resuelto. Ya estamos conectados a nuestro IRIS desde el Visual Studio Code WebGateway mediante.

Espero que os resulte de utilidad.

Discussão (0)1
Entre ou crie uma conta para continuar
Resumo
· Mar. 17