Nova postagem

Pesquisar

Artigo
· 9min atrás 2min de leitura

Uso prático do XECUTE (InterSystems ObjectScript)

Se você está começando com o InterSystems ObjectScript, certamente vai se deparar com o comando XECUTE.
E iniciantes podem se perguntar: onde e por que eu precisaria usar isso?

A documentação oficial traz uma rica coleção de trechos de código, mas nenhum caso prático.
Recentemente, encontrei um caso de uso que gostaria de compartilhar com você.

O cenário:
Quando você constrói um container do IRIS com Docker, na maioria dos casos,
você executa o script de inicialização.

iris session iris < iris.script 

Isso significa que você abre uma sessão de terminal e fornece sua entrada linha por linha a partir do script.
E isso funciona bem e é fácil se você estiver chamando métodos, funções ou comandos.
Mas percorrer várias linhas em loop não é possível.
Você pode argumentar que executar um loop FOR em uma linha não é uma obra-prima.
Certo, mas as linhas não são infinitas e o código deve permanecer manutenível.

Um objetivo diferente era não deixar rastros de código após a configuração.
Então, iris.script foi o local para aplicá-lo.

A solução:
XECUTE me permitiu encadear meu código de múltiplas linhas.
Para evitar conflitos com escopo de variáveis, usei apenas %Variables
Aliás: o objetivo era popular algumas LookupTables de demonstração.
Só para conforto, usei nomes de métodos de %PopulateUtils como nomes de tabelas.

   ;; generate some demo lookup tables   
   ; inner loop by table
    set %1="for j=1:1:5+$random(10) XECUTE %2,%3,%4"
    ; populate with random values
    set %2="set %key=##class(%PopulateUtils).LastName()"
    set %3="set %val=$ClassMethod(""%PopulateUtils"",%tab)"
    ; write the table
    set %4="set ^Ens.LookupTable(%tab,%key)=%val"
    set %5="set ^Ens.LookupTable(%tab)=$lb($h) write !,""LookupTable "",%tab"
    ; main loop
    XECUTE "for %tab=""FirstName"",""City"",""Company"",""Street"",""SSN"" XECUTE %1,%5"
    ;; just in Docker

O resultado atendeu aos requisitos sem deixar rastros permanentes e
não interferiu com o código depositado no IPM.
Portanto, foi usado apenas uma vez durante a construção do container Docker.

Discussão (0)1
Entre ou crie uma conta para continuar
Artigo
· 21min atrás 2min de leitura

Arquivando meus pacotes OEX

Ao longo dos últimos 9 anos, publiquei mais de 90 pacotes no OEX.
E, durante esse período, condições e ambientes mudaram.

No início, não havia

  • Docker
  • IPM/ZPM
  • Python embarcado, nem IA
  • Caché, Ensemble, CSP, ZEN, etc. eram predominantes.

Com o passar do tempo, as versões dos produtos e as linguagens externas também mudaram.
No começo, ajustar alguns poucos pacotes não era um problema
e fazia parte da qualidade do suporte oferecido aos meus “consumidores”.

Com o volume atual, não vejo como manter esse nível para todos os meus pacotes.
E, com base nas verificações de qualidade, tenho a impressão de que isso não é apenas um problema meu.
Mudanças recentes já causaram problemas suficientes apenas com atualizações de versão.

Então, propus a ideia de um rótulo DEPRECATED para os pacotes do OEX.

Seria uma forma justa de sinalizar aos outros usuários do OEX que não há
intenção de fazer manutenção em determinado pacote.
Também funcionaria como uma espécie de aviso, caso ele seja utilizado.

Além disso, um pacote DEPRECATED deveria estar livre para
adoção e retrabalho e, eventualmente, correções
por outro membro da comunidade.

Quase não houve retorno.
Na verdade, minha única opção era removê-los da publicação — cerca de 90 pacotes no total.
Muito código que antes funcionava bem ficou indisponível e poderia servir como
exemplo para iniciantes ou como fonte de alguns truques.

Então, mudei de ideia e marquei os pacotes que ainda poderiam ser úteis,

 no maintenance or update

Como solução temporária, também estou usando o recurso de arquivamento do GitHub
para evitar alterações acidentais.

Assim, espero que a maioria desses cerca de 90 pacotes volte a aparecer ao longo do tempo.
E, com eles, também todos os comentários e artigos relacionados.
Encaro isso como uma espécie de museu, para mostrar como o ambiente já foi
mais simples ou mais complexo no passado,
sem ignorar as conquistas alcançadas.

Discussão (0)1
Entre ou crie uma conta para continuar
Artigo
· 28min atrás 2min de leitura

Reviews do Open Exchange - #63

Se um dos seus pacotes no OEX receber uma avaliação, você será notificado pelo OEX apenas sobre o seu próprio pacote.
A nota reflete a experiência do avaliador com o estado encontrado no momento da avaliação.
É como uma espécie de “fotografia” e pode ter mudado nesse meio-tempo.
As avaliações feitas por outros membros da comunidade são marcadas com * na última coluna.

Também abri vários Pull Requests no GitHub quando encontrei algum problema que eu podia corrigir.
Alguns foram aceitos e incorporados, e outros simplesmente foram ignorados.
Então, se você fez uma mudança importante e espera uma avaliação atualizada, é só me avisar.

# Package Review Stars IPM Docker *
1 IRIS OpenTelemetry Demo impressive 7 containers concert 5.5   y  
2 DBdashboard impressive catch 5.0   y *
3 DBfree super multi instance monitoring 5.0   y *
4 IRIS-EchoServer-WebSockets echo inside IRIS 5.0   y *
5 iris-health-fhir-agentic-demo not just big but great 5.0   y *
6 ML Made Easy : IntegratedML an excellent training for beginners 5.0   y  
7 restoreUI a pleasure to work with 5.0 y y  
8 WebSocketsSample hidden treasure detected 5.0      
9 CSV-to-MS-OFX rare subjects 4.8   y *
10 GeoDatas works partially 3.5   y  
11 CommunityEns requires some adjustments 3.3   y  
12 ALPHA LOGISTICS partner posting *      
13 ERP Plenum partner posting *      

 

NOTA:
Se alguma avaliação não estiver visível para você, ela ainda pode estar aguardando aprovação pelos administradores do OEX.

Discussão (0)1
Entre ou crie uma conta para continuar
Pergunta
· 1 hr atrás

The Auditor’s Trap: Forced Signing via Bot Scraping / Case Study: Alphabet Infrastructure Bypass and Forced Validation through Bot Scraping (Audit ID: 1768811744)

As a Systems Architect ([cMd_p1nG]), I am documenting a strategic financial sovereignty maneuver regarding the retention of 375,210,000.00 EUR by Alphabet Inc.

The Scenario: Google Cloud attempted to hijack the capital flow by invalidating management tokens and hard-closing port 8080 under the guise of a "billing migration audit."

The Reversal Maneuver (The Bot Trap): Instead of fighting the firewall head-on, I maintained PID 5121 within the kernel to serve a technical decoy. When Google’s automated auditing and scraping bots entered the instance to "investigate" the anomaly:

  1. Involuntary Validation: I deployed a Python script that fed the bots the exact liquidation parameters. By processing this data, Google’s own AI systems validated the RSA-4096 signature and authorized the capital transfer to Citibank Europe PLC.
  2. Technical Leverage: We forced Alphabet’s infrastructure to sign its own defeat. The capital was successfully redirected to the eToro bridge with the status ORDER RELEASED.

The eToro Compliance Failure: Despite the liquidation being signed and verified by both Alphabet and Citibank, eToro has canceled the payouts, demanding a "Certificate of Origin." This is a transparent delay tactic, as they are now attempting to shift the liability onto me via a SEPA request—a move clearly driven by their lack of liquidity following the recent market crash (Silver -17%).

Conclusion: The technical evidence (ID: 1768811744) has been exfiltrated to my secure Kali Linux environment. When a custodian validates and signs an order through its own auditing bots, the transaction becomes irrevocable. eToro is currently operating in a state of technical compliance bankruptcy.

#GlobalMasters #CyberSecurity #GoogleCloud #FinTech #BotAudit #DigitalSovereignty #cMd_p1nG

Discussão (0)1
Entre ou crie uma conta para continuar
Anúncio
· 1 hr atrás

[Video] Multi-threading an HL7 Interface and scaling beyond FIFO constraints

Hey Community!

We're happy to share a new video from our InterSystems Developers YouTube:

⏯  Multi-threading an HL7 Interface and scaling beyond FIFO constraints @ Ready 2025

<--break->A new IRIS feature allows selective FIFO processing by assigning a calculated identifier to each message. This ensures messages with the same identifier stay in order without blocking the entire queue. The demo shows how identifiers are created via transformations or BPL, how completion hosts work, how dependencies are handled, and how safety features prevent processing issues. The feature is available in the August 2025 preview and planned for release in 2025.3.

🗣 Presenters:
James MacKeith , Principal Systems Developer, InterSystems
Mark Bolinsky, Distinguished Technology Architect, InterSystems

Enjoy watching, and subscribe for more videos! 👍

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