Nova postagem

Pesquisar

Artigo
· Abr. 24, 2024 4min de leitura

Cómo instalar soluciones ObjectScript sin código fuente o en modo de despliegue mediante el gestor de paquetes IPM

¡Hola, amigos!

A menudo, cuando desarrollamos soluciones comerciales, existe la necesidad de desplegar soluciones sin código fuente, por ejemplo, para preservar la propiedad intelectual.

Una de las formas de conseguirlo es utilizar InterSystems Package Manager.

Aquí he pedido a Midjourney que pinte una propiedad intelectual de software:

¿Cómo se puede lograr esto con IPM?

De hecho, es muy sencillo; basta con añadir la cláusula Deploy="true" en el elemento Resource del manifiesto module.xml. Ver Documentación.

He decidido pasaros el ejemplo más simple posible para ilustrar cómo funciona y también para daros una plantilla de entorno de desarrollo que os permita empezar a construir y desplegar vuestros propios módulos sin código fuente. ¡Allá vamos!

A continuación se muestra la aplicación de plantilla de ejemplo de Open Exchange que contiene dos clases:

 dc.deployed.ObjectScript y dc.withsource.ObjectScript 

Como se deduce del nombre, es un ejemplo de modo despligue sin código fuente. Se utiliza otra clase con código fuente para ilustrar la diferencia y la opción de combinar los modos despliegue y código fuente.

Así es como podéis probarlo:

Iniciad IRIS como:

docker run --rm --name iris-demo -d -p 29091:1972 -p 29092:52773 intersystemsdc/iris-community

y, a continuación, abrid el terminal IRIS:

docker exec -it iris-demo iris session iris

Después, instalad el módulo:

zpm "install deployed-oscript-template"

Se deberían instalar dos clases en el espacio de nombres. Comprobemos el código fuente. Haced la siguiente llamada:

Do ##class(dc.deployed.ObjectScript).Test()

Deberíais ver esto:

USER>Do ##class(dc.deployed.ObjectScript).Test()  

It is a deployed class without source code!

Y si llamáis a otro método para imprimir el código fuente de la clase:

k text do ##class(%Compiler.UDL.TextServices).GetTextAsString($namespace, "dc.deployed.ObjectScript", .text) w text

Sólo veréis el nombre de la clase y las firmas de los métodos:

Class dc.deployed.ObjectScript

{



ClassMethod Test() As %Status
{

}



}

Y si llamamos a otra clase con código fuente veréis:

USER>Do ##class(dc.withsource.ObjectScript).Test()

This class installed with a source code!

 

USER>k text do ##class(%Compiler.UDL.TextServices).GetTextAsString($namespace, "dc.withsource.ObjectScript", .text) w text
Class dc.withsource.ObjectScript

{

ClassMethod Test() As %Status
{

    set a=42
    write "This class installed with a source code!",!

    return a

}



}

 

Podéis aprovechar el repositorio para probar la función de modo de despliegue. A continuación se muestran los pasos de ejemplo para gestionarlo.

Clonar el repositorio

$ git clone https://github.com/intersystems-community/objectscript-docker-template.git

Abrid la carpeta en VSCode e iniciad docker en el terminal VSCode:

$ docker-compose up -d

Refrescad la conexión del VSCode para conectar con el contenedor IRIS. Realizad cambios en IRIS ObjectScript Classes y module.xml (o no lo hagáis) y luego cargad el código fuente en IRIS Terminal:

USER>zpm "load /home/irisowner/dev"

Cambiad el cliente IPM de la comunidad predeterminada al registro de prueba (está disponible todo el tiempo para realizar pruebas de IPM):

USER>zpm

zpm:USER>repo -n registry -r -url https://test.pm.community.intersystems.com/registry/ -user test -pass PassWord42

y publicad el módulo en el registro de pruebas:

zpm:USER>publish deployed-oscript-template

Por supuesto, podéis cambiar el nombre del módulo en module.xml (así como los recursos de código que publicáis).

Comprobad si el módulo está publicado:

zpm:USER>find

Como se puede ver el módulo fue publicado con éxito.

Si deseáis probar que el módulo recién publicado se instala sin código fuente es fácil de hacer con otra instancia IRIS iniciada en el contenedor docker. Esto se puede realizar de la siguiente manera. Iniciad un contenedor con IRIS en el terminal:

docker run --rm --name iris-demo -d -p 29091:1972 -p 29092:52773 intersystemsdc/iris-community

Abrid el terminal IRIS:

docker exec -it iris-demo iris session iris

Iniciad la consola IPM:

USER>zpm

Cambiad al registry de IPM para pruebas (test):

repo -n registry -r -url https://test.pm.community.intersystems.com/registry/ -user test -pass PassWord42

Instalad vuestro módulo (cambiadlo si lo habéis publicado con otro nombre):

zpm:USER>install deployed-oscript-template

Probad el funcionamiento del módulo y el código fuente como hicimos anteriormente.

Y ya está. 

¡Felices innovaciones y despliegues con IPM e InterSystems IRIS!

Discussão (0)1
Entre ou crie uma conta para continuar
Pergunta
· Abr. 24, 2024

Line Terminators and File/Stream Classes - A Few Questions

Hello, I'm curious to see how other people deal with this: we have a text file that was created on someone's Windows machine and it was copied and pasted into a text file on someone's Mac machine.  After some examination we realized that the line feeds were originally CRLF (for Windows) and when copied and pasted they were changed to LF (Mac).  The diff program we used didn't pick up on this and the program we wrote to read the file was getting each line of the CRLF file and treating the whole file as one line for the LF file. 

I was able to use the text editor to change the LF file back to CRLF to fix the problem short term.  The long term solution was to simply set the line terminator to LF in the program itself.  My question is: is this reliable?  Why wouldn't the default line terminator just be LF in all cases?  That covers it for both Windows and Unix.  I'm trying to imagine the use case of why it's important to default to CRLF for Windows and LF for Mac.  Maybe someone can assist?

Maybe things are more complicated when you are dealing with things that aren't text files? I can understand the need to set the line terminator because it could be any character for any use case, but what I'm really curious about is the default for Windows and Unix when LF covers them both.  This could present problems if app users are trying to load files and through the magic of copying and pasting they change these control characters without even realizing.  

Speaking of line terminators, here's another quandary.  The file in question is loaded from a form submit from a CSP server page.  This means the file is presented to the server as a %CSP.BinaryStream.  Do folks agree that in general the methods to use %CSP.BinaryStream as similar but not totally consistent with %Stream.FileBinary and %Stream.FileCharacter?  Or are the similar enough that you shouldn't have a problem treating them as the same class really?

When it comes to line terminators however, %Stream.FileBinary does this:

property LineTerminator as %String (MAXLEN = 10) [ InitialExpression = $get(^%SYS("Stream","LineTerminator"),$select($$$isUNIX:$char(10),1:$char(13,10))) , Transient ];

and %CSP.BinaryStream does this:

property LineTerminator as %String (MAXLEN = 10) [ InitialExpression = $char(13,10) ];

Maybe I need a better primer on streams.  If you have a good resource, I'm happy to read!

2 Comments
Discussão (2)1
Entre ou crie uma conta para continuar
Pergunta
· Abr. 24, 2024

Unable to access web Gateway via IIS

Hi

I've installed Ensemble 2018 then enabled IIS from Win features, then realized that CSPGateway doesn't exit so I downloaded and installed CSPGateway-2018 from WRC.

so now I'm trying to set up a Website application and facing some issues, and I think IIS and CSPGateway in inetpub are not connecting or synchronising properly but mostly is accessing Web gateway via IIS my understanding is that I can access using the following url http://machinename/csp/bin/Systems/Module.cxw  using my machinename or IP but it's not happening.

I can access the gateway from Managment portal with this url http://localhost/csp/bin/Systems/Module.cxw 

do I need to have IIS installed in windows features before installing Ensemble!?

 

Thanks  

12 Comments
Discussão (12)5
Entre ou crie uma conta para continuar
Pergunta
· Abr. 24, 2024

Fallo de conexión SQL Gateway a base de datos SQLServer

Estoy intentando realizar una conexión a una base de datos de SQLServer, pero recibo este error:

ERROR <Ens>ErrOutConnectFailed: JDBC Connect failed for 'SQLEmails' (jdbc:sqlserver://;serverName=nombredelservidor.es;databaseName=DKVMAIL_PRE) / 'SQLSeverDKVMAIL_PRE' with error ERROR #5023: Remote Gateway Error: JDBC Gateway connection failed for jdbc:sqlserver://;serverName=nombredelservidor.es;databaseName=DKVMAIL_PRE error: Remote JDBC error: com.microsoft.sqlserver.jdbc.SQLServerException: The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: "sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target". ClientConnectionId:433d4b77-1dc0-4a48-8cf9-528bd64a7cba.

Parece que hay un problema en la conexión vía SSL, pero no veo donde podría configurarlo dentro de la configuración del SQL Gateway. ¿Alguna idea?

Gracias

2 Comments
Discussão (2)2
Entre ou crie uma conta para continuar
Anúncio
· Abr. 24, 2024

[Vidéo - EN] HealthShare Health Connect - Automatisation de la mise à niveau avec le validateur de production

Bonjour la Communauté,

Cliquez sur play et plongez-vous dans notre nouvelle vidéo sur InterSystems Developers YouTube:

⏯ HealthShare Health Connect - Upgrade Automation with Production Validator @ Global Summit 2023

Mettez-vous à niveau ou migrez-vous des systèmes sur vos instances Health Connect ou IRIS for Health ? Rejoignez-nous pour en savoir plus sur les prochains outils Production Validator, conçus pour améliorer votre flux de mise à niveau et/ou de migration et le rendre plus efficace. Écoutez les témoignages de clients qui ont contribué à façonner les outils pour garantir un délai de rentabilisation.

Présentateurs: 
🗣 @John Goodgame, Senior Sales Engineer, InterSystems
🗣 @Justin Owens, Programmer Analyst, Orlando Health
🗣 @Scott Roth, Senior Application Development Analyst, The Ohio State Wexner Medical Center
🗣 @James Bourette, Distinguished Systems Developer, InterSystems

Bonne lecture de cette vidéo et restez à l'écoute ! 👍

Discussão (0)1
Entre ou crie uma conta para continuar