Find

Digest
· 2 hr ago

InterSystems 开发者社区中文版：每周摘要（2025年11月10日-16日）

#Digest #Developer Community Official
十一月 10 - 16, 2025Week at a GlanceInterSystems Developer Community
Article
· 11 hr ago 2m read

Network Debugging for Beginners - 2

#Caché #Ensemble #HealthShare #InterSystems IRIS

In my previous article, I structured network communications
in these 3 possible layers, and covered the last

  • Client <---> Transport
  • Server <---> Transport
  • Client <---> Server

In fact, you have the most control over the last one.
The IRIS side as a server is yours and under your full control. 
Up to now, the Transport layer was assumed to be as passive as a bare wire.

This assumption should be verified. I once met a Windows environment with
a quite surprising setup where a Firewall-like filter was isolating internal
processes and causing a lot of trouble.

? What can you do about the  Transport section ?

In a typical setup, firewalls filter and/or block selected connections by Web Address
or by type of protocol.  WebSockets seems to be one of their preferred targets.  
And even Microsoft's IIS requires special settings to pass along the WebSocket protocol.

Now we have reached the wire. If there is no direct connection as in a LAN,
every router you have to pass is expected to just forward messages.
Though they might also be a show stopper, acting like a firewall.

It's eventually a rare case, but it could never be excluded.
And there is still another dimension related to the Transport.
Earlier we have seen what we think to receive and what we expect to send.

? Is this the reality out on the wires ?

I know of 2 tools I have used that helped me along often.
Both act by the same principle as a tunnel and mimic client and server.
Receive messages, log them with timestamps, and forward them to the other end.

The ultimate tool is Wireshark. I guess no bit on the wire can escape from it.
Though it is easy to start, the correct interpretation is a science that requires
related experience and deep digging into details.
Being in networks for almost 60 years, it was the best tool in that area I have ever met.
It is to me what Mona Lisa might be for painters or Mount Everest for climbers.

But in most average troubleshooting exercises it's an overkill.
TCPtrace creates a tunnel and keeps track of what is going forward and back.
For some time, it is also able to handle UDP protocol too.
And it is really easy to handle and to consume! 

As you have seen in the simple example with  our management portal:

  • What you see in IRIS in the CSP page is HTML and JavaScript
  • What you see in the browser is also just HTML and JavaScript
  • But invisible and under cover, headers and cookies are traveling along

You may face situations where your problem is exactly hidden there.
The experiment with manually composed HTML showed it.

Discussion (0)1
Log in or sign up to continue
Article
· 11 hr ago 3m read

Network Debugging for Beginners - 1

#Caché #Ensemble #HealthShare #InterSystems IRIS

Chasing errors or misbehavior in the network can be quite a challenge.
Differently to  a local application on the DB server, you always have at least 3 players:

  • A client  to place a request 
  • some kind of transport layer
  • and a server to provide a reply.

This results in a minimum of 3 possible communication layers

  • Client <---> Transport
  • Server <---> Transport
  • Client <---> Server

The last one is probably the easiest  to check, while the other 
two deal with the same counterpart just from opposite sides.

?  Do both ends use the same communication protocol ?

I met more than once that one end expected to use TCP protocol,
but the other side was using UDP or WS (WebSockets) or whatever.
And IF they match ?

? How does the request look?

You may direct a request for a CSP page to a private port
Using 773 instead of 52773 for the IRIS Management Portal

USER>set port="|TCP|777"
USER>open port:(:773):1 write  $t
1
USER>use port read what  

Now  you launch your request from the browser  http://localhost:777/csp/sys/UtilHome.cs
and see

USER>write what
GET /csp/sys/UtilHome.csp HTTP/1.1
Host: localhost:773
Connection: keep-alive
sec-ch-ua: "Chromium";v="142", "Google Chrome";v="142", "Not_A Brand";v="99"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.9,de-AT;q=0.8,de;q=0.7
Cookie: state-B88AC959-5DBA-11F0-86C0-0242C0A80002=/5jOrv7mM4MMdJCVpOCgtb1j0WTGCB4RZF2IHT4Og+4%3D%3ASYSEXP%3A; state-84BBBB0F-94B2-11F0-BAB4-0242C0A80006=/5jOrv7mM4MMdJCVpOCgtb1j0WTGCB4RZF2IHT4Og+4%3D%3ASYSEXP%3A; state-1E3B3956-9A2D-11F0-AD45-0242C0A8000B=7xLBuIkd9LEHE63vfvhZkekO0SUMlGruyPOWuYCUrt8%3D%3ASYSEXP%3A;
USER>

The first lines tell you that your request is using HTML on top of HTTP
That means that HTML is used as the content protocol embedded in HTTP

Your port 773 is bi-directional.
So you might be tempted to compose an HTML wrapped reply and send it back just like  

USE port WRITE "<H1>some friendly welcome</H1>",!

As this is not proper HTML and as you miss all required headers and other credentials
for a clean HTTP communication, your Browser may dislike it at least.
Therefore, the next question:

? How does the proper reply look like ?

There is a utility tool in IRIS  to examine the reply to some level.

USER>DO $system.CSP.Shell()
CSP:USER>>>GET /csp/sys/UtilHome.csp

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: CSPSESSIONID-UP-csp-sys-=3100      3100; path=/csp/sys/;  httpOnly; sameSite=strict;
Cache-Control: no-cache,no-store
Date: Sun, 16 Nov 2025 15:05:37 GMT
Expires: -1
X-Frame-Options: SAMEORIGIN
<html lang="de" >
<head>
<title>IRIS - Home</title>
<link rel="stylesheet" type="text/css" 
. . . . . . . . .

You should enable logging for the terminal to study this 120k byte reply in detail

Now it is your next step to dig deeper.

For our example with the CSP page and a browser client, you have 3 options:

  1. :  Use your browser development tools to examine the content
  2. :  Use JavaScript alert()  to display some inner invisible content
  3. :  Use JavaScript combined with HTML textarea for more content   

At the server end in IRIS, it's a bit easier.

Every CSP page generates a class, which also generates an INT routine
You have the option to add debugging code at all levels
Just as you would do for any normal background job.
Most likely, this is a sequence that is looping until manually released,
or just some kind of individual tracing with ^ERN or a similar approach.

And this works not just for CSP pages but also for %REST processing.

? And what about the Transport step ?

See part 2 of Network Debugging for Beginners 
Network Debugging for Beginners - 2

Discussion (0)1
Log in or sign up to continue
Article
· Nov 15 1m read

Amostra de código para concatenar arrays JSON

#Code Snippet #JSON #InterSystems IRIS

O ObjectScript não inclui nenhum método embutido para anexar um array dinâmico JSON a outro. Aqui está um trecho de código que uso, que é equivalente ao método concat() do JavaScript.

Chame-o com qualquer número de argumentos para concatená-los em um novo array. Se um argumento for um array dinâmico, seus elementos serão adicionados. Caso contrário, o próprio argumento será adicionado.

Discussion (0)1
Log in or sign up to continue