发布新帖

查找

文章
· 二月 16, 2023 阅读大约需 2 分钟

Rompe los límites del servidor

¡Hola, desarrolladores!

Sois expertos en IRIS y conocéis todos los trucos.
Las funcionalidades $ZF() y CPIPE no son nuevas para vosotros.
Así que también conocéis los límites de estas funcionalidades.
Ambos dan acceso a su entorno de servidor local. Y este es el final.
En muchos casos esto es perfectamente suficiente.
PERO :
Si IRIS se ejecuta en un contenedor Docker, está bloqueado y
aislado en ese contenedor. Este es el concepto básico del contenedor.
Puede ingresar al contenedor desde el exterior y recopilar datos.
Pero nada puede salir del contenedor sin una consulta. ¡Muy bien!
Esto hace que las funciones $ZF() y CPIPE sean casi inútiles.

¡Basta de quejarse! Habéis entendido el problema.
He pensado en una posible solución para escapar de esta prisión.
Pero debe tener la misma funcionalidad o mejor... ¿cómo mejor?
Desde IRIS/Caché nunca tengo más privilegios en el sistema host
que IRIS/Caché o mi terminal. Esta es una limitación incómoda,
especialmente en el contenedor Docker.

Mi solución se ve así:
Comienzo un programa esclavo donde quiero ejecutar mis comandos.
No un Espartaco, porque debe hacer exactamente lo que le digo. Y nada más.
Resulta que esto no solo es útil para los contenedores Docker, sino en general
para todas las situaciones en las que no estoy hablando con mi servidor host directo, 
sino con algún sistema que me está escuchando. 

La técnica específica:
He creado dos programas esclavos (en Python y C++) que escuchan en un puerto TCP.
Y un comandante en COS que envía las órdenes y puede estar esperando comentarios.
Dado que me estoy comunicando a través de TCP, el proceso esclavo puede estar en
cualquier lugar de la red en la medida en que lo permita el firewall.
Además, puedo otorgar a mis procesos esclavos exactamente los privilegios 
que considero correctos y necesarios, independientemente de IRIS/Caché. 
Ese fue un efecto secundario agradable y no planificado.

Los ejemplos para los programas esclavos y el comandante, así como los ejemplos,
también están disponibles en GitHub.

¡Espero que haya sido interesante! Podéis votar mi artículo en el 2º Concurso de Artículos Técnicos.

¡Saludos cordiales desde Viena!

Nota.- La traducción al inglés estará disponible en marzo cuando termine el concurso.

1 条新评论
讨论 (2)1
登录或注册以继续
问题
· 二月 14, 2023

SOAP - How to create soap and call my StoredProc function from external website?

Hi Every one

 

I'm working on how to use SOAP with my API and StoredProc.

Currently, the method I use is csp page to be able to get pamater from external website and Call my StoredcProc
Step 1 Get pamameter from external site
Step 2 Run My Storeproc
Step 3 Return JSON format

 

How to create soap and call StoredProc function from external website?

3 Comments
讨论 (3)2
登录或注册以继续
文章
· 二月 12, 2023 阅读大约需 3 分钟

Enabling IRIS Interoperability Source Control with InterSystems Package Manager and git-source-control

Hi Developers!

As you know InterSystems IRIS Interoperability solutions contain different elements of the solution, such as: production, business rule, business process, data transformation, record mapper. And sometimes we can create and modify these elements with UI tools.  And of course we need a handy and robust way to source-control the changes made with UI tools.

For a long time this was a manual (export class, element, global, etc) or cumbersome settings procedure, so the saved time with source-control UI automation was competing with lost time to setup and maintain the settings.

Now the problem doesn't exist any more. With two approaches: package first development and usage of IPM package git-source-control by @Timothy Leavitt 
.

Meme Creator - Funny WOW IT REALLY WORKS Meme Generator at MemeCreator.org!

The details are below!

Disclaimer: this relates to a client-side approach of development, when the elements of the Interoperability production are the files in the repository.

So, this article will not be long at all, as the solution is fantastically simple.

I suppose you develop with docker and once you build the dev environment docker image with IRIS you load the solution as an IPM module. This is called "Package first" development and there is the related video and article. The basic idea is that dev-environment docker image with iris gets the solution loaded as package, as it is being deployed on a client's server.

To make a package first dev environment for your solution add a module.xml into the repository, describe all the elements of it and call "zpm load "repository/folder" command at a building phase of docker image.

I can demonstrate the idea with the example template: IRIS Interoperability template and its module.xml. Here is how the package is being loaded during docker build:

zpm "load /home/irisowner/irisdev/ -v":1:1

the source. 

See the following two lines placed before loading the package source control. Because of it source control starts working automatically for ALL the interoperability elements in the package and will export it in a proper folders in a proper format:

zpm "install git-source-control"
do ##class(%Studio.SourceControl.Interface).SourceControlClassSet("SourceControl.Git.Extension")

the source

How is it possible?

Since recently git-source-control app supports IPM pakcages for source control that are loaded in a dev mode. It reads the folder to export, and imports the structure of sources from module.xml. @Timothy Leavitt can give provide more details.

If we check in terminal the list of IPM modules after the environment is built we can see that loaded module is indeed in dev mode:

USER>zpm
=============================================================================
|| Welcome to the Package Manager Shell (ZPM).                             ||
|| Enter q/quit to exit the shell. Enter ?/help to view available commands ||
=============================================================================
zpm:USER>list
git-source-control      2.1.0
interoperability-sample 0.1.2 (DeveloperMode)
sslclient               1.0.1
zpm:USER>

Let's try? 

I cloned this repository, opened in VSCode and built the image. And below I test Interoperability UI and source control. I make a change in UI and it immediately appear in the sources and diffs:

It works! That's it! 

As a conclusion, what is needed to let you have source control for Interoperability UI elements in your project:

1. Add two lines in iris.script while building docker image:

zpm "install git-source-control"
do ##class(%Studio.SourceControl.Interface).SourceControlClassSet("SourceControl.Git.Extension")

And load your solution as a module after that, e.g. like here:

zpm "load /home/irisowner/irisdev/ -v":1:1

2. Or you can start a new one by creating repository from Interoperability template.

Thanks for reading! Comments and feedback are welcome!

8 Comments
讨论 (8)3
登录或注册以继续
讨论
· 二月 6, 2023

Upgrade Iris for Health to 2021.1.2 checklist

If anyone has a custom checklist of tasks that must absolutely be done when doing this upgrade to make sure everything is included and nothing is lost or destroyed, we would greatly appreciate it? We have the generic checklist provided on the support websites but we run custom build classes, ftp, tcp-ip, batch, etc.

Thanks,

Jonathan Harris

2 Comments
讨论 (2)3
登录或注册以继续
问题
· 二月 3, 2023

Why to run ISC Agent in Demo Docker ?

For quite some time I am bored by slowly starting Docke Demos from OEX.
I type

docker-compose up - d

and after a few seconds

docker-compose logs

And I just see ISC Agent was started and is hanging around
No IRIS instance is up yet.

To my understanding, ISC Agent  is totally useless in this single server instance
So with some investigations, I found a start parameter to avoid this behavior.
And now my IRIS instances start immediately (or what you can expect in a container).
What is it:  --ISCAgent false  applied in docker-compose.yaml:

 Is there any reason not to do it if no MIIROR is in the game ? 
Or any other reason or requirement?

2 Comments
讨论 (2)1
登录或注册以继续