最後にCSP機能の中でReactでうまく置き換えできなかった処理について紹介します。

該当する処理は、サーバー上の商品データに含まれるその商品の画像データ（GIF形式）を取得して、ブラウザにイメージとして描画させるものです。

CSPにはStreamServer.clsというサーバー側で動作する機能が用意されています。

この機能を使ってデータベース上に格納されているストリームデータをHTML IMGタグで処理できる形式に変換してくれます。

StreamServer機能を使って画像を表示する処理

Reactで同様の機能を実現する方法が見つからなかったため（そもそもReactはサーバーサイドではなくクライアント上の技術なので）、データベース内に格納されているイメージを取得するのではなく、静的なイメージファイルをウェブサーバーが参照可能な場所に置くことで解決しました。

これは InterSystems FAQ サイトの記事です。

Embedded Pythonでトランザクションを実装するために、以下のようなAPIが用意されています。

import iris  
       iris.tlevel()
       intval = iris.tstart()
       iris.tcommit()
       iris.trollbackone()
       iris.trollback()

詳細はドキュメントをご覧ください。

** 2018年2月12日改訂

この記事はInterSystems IRISに関するものですが、Caché、Ensemble、およびHealthShareのディストリビューションにも適用されます。

概要

メモリはページ単位で管理されます。 Linuxシステムでは、デフォルトのページサイズは4KBです。 Red Hat Enterprise Linux 6、SUSE Linux Enterprise Server 11、およびOracle Linux 6では、HugePageと呼ばれるシステム構成に応じて、ページサイズを2MBまたは1GBに増やす方法が導入されました。

以前の記事では Arduino を使い始め、最終的には気象観測所のデータを表示できるようになりました。 この記事ではさらに掘り下げ、InterSystems Caché アプリケーションに対して RFID カードと Arduino を介した認証をセットアップします。

これは InterSystems FAQ サイトの記事です。

管理ポータルから行う手動のパージ（Purge）と、タスクを利用する方法があります。

データを手動でパージするには、[Interoperability] > [管理] > [管理データの削除] ページを使用します。
（このページではバックグラウンド・ジョブとしてパージを実行しますので、ページがタイムアウトしても問題ありません。）

タスクでパージする場合は、[システムオペレーション] > [タスクマネージャ] > [新しいタスク] の画面でInteroperabilityプロダクションのネームスペースを指定し、タスクタイプに「Ens.Util.Tasks.Purge」を指定します。

タスクの場合は、「TypesToPurge」の項目で以下のパージ対象タイプを選択できます（図参照）。

デバッガーは使わないという人はいますか？ 最後に使ったのはいつだったか、記憶にないですね。 それは、嫌いだからではなくて、単に必要ないからなんです。 その一番の理由は、ある種の開発手法を使っているおかげで、バグの発生を少なく抑えたり、単体テストのレベルで発見したり、バグをとても簡単に追跡できたりするからです。

以下にいくつかヒントを紹介します...

1. 独自の COS チートシートを作成する。

これは主に COS の初心者が対象になります。 バグを引き起こす大きな原因の一つとして、特定のコマンドや関数の動作を理解していないということがあります。 時間をかけて言語を学び、そのすべてのバリエーションを試すことをおすすめします。 それから独自のチートシートを作成することで、知識が固まり、さっと使えるレビューツールも出来上がります。 生産性アップにつながるほか、避けられるはずのバグをうっかり書いてしまう頻度を確実に減らすことができます。

2. スタジオで「変数の追跡」をオンにする

これは InterSystems FAQ サイトの記事です

Web サービス(SOAP)またはREST で IIS を経由してクライアントにエラー応答する際、既定では IISが生成するデフォルトのエラーページ( HTTP 500 エラー )が返されます。

SoapFaultなど、サーバ側で出力したエラーの詳細情報は返されません。

IIS7 以降、WebクライアントがWeb サービスの障害の詳細情報を取得するための設定オプションが追加されました。

HTTP ステータスコードがエラーの場合に、既存の応答をどうするかを existingResponse 属性で指定することができます。

こちらの値を、既定の Auto から PassThrough に変更することで、エラーの詳細情報が返されるように変更できます。
※設定変更後、IISの再起動が必要です。

質問

現在使っているリレーショナルデータベースからInterSystems IRIS Data Platformに移行することは可能ですか？

答え

InterSystems IRIS Data Platform（以下IRISと表記）は、SQLをサポートしていますので、多くの場合リレーショナルデータベースで構築されたアプリケーションは、大部分のコードを変更することなくIRISに移行することができます。

ただしSQLの各実装毎にSQL標準を拡張した仕様等があり、それにIRISが全て対応していませんので、コードの書き換えが必要なケースもあります。

また各実装が独自に用意した標準でない通信系API等にも対応していませんので、その場合にはJDBC、ODBCなどの標準的な通信APIに置き換える必要があり、かなり書き換えが必要になります。
（使用されているSQL文等はそのまま流用可能な場合が多いです。）

さらにそのままコードを移行できるケースであっても動作保証はできませんので、必ず動作確認のためのテスト作業は必要になります。

この記事では、syslogテーブルについて説明したいと思います。 syslogとは何か、どのように確認するのか、実際のエントリはどのようなものか、そしてなぜそれが重要であるのかについて説明します。 syslogテーブルには、重要な診断情報が含まれることがあります。 システムに何らかの問題が生じている場合に、このテーブルの確認方法とどのような情報が含まれているのかを理解しておくことが重要です。

中間データベースを使用して、Grafana と IRIS（または Cache/Ensemble）を使用する方法を説明した非常に有益な記事がコミュニティにいくつか掲載されています。

しかし私は、IRIS 構造に直接アクセスしたいと考えていました。 特にこのリンクで説明しているように、SQL でアクセス可能なCaché履歴モニターのデータにアクセスしたかったのです。

https://community.intersystems.com/post/apm-using-cach%C3%A9-history-mon...

また、データをいじりたくもありませんでした。

必要とするデータを返すクラスクエリはすでにあったので、それらを、JSON を返す REST クラスに埋め込むだけで良かったからです。 クラス Grafana.MonitorData はまだ含めていません。それでなければならないという理由があるわけではなかったためですが、要望があれば、含めることは可能です。

これは InterSystems FAQ サイトの記事です。

仮想ドキュメント（以降VDOC）とは複雑な構造のドキュメント（メッセージ）を効率良く高速に処理するために考えられたメッセージ処理の仕組みです。

HL7に代表される EDI 標準は電子データ交換のための汎用的なかなり複雑なメッセージ形式を含んでいます。

また、メッセージの種類を増やすと運用が複雑になってしまうため、1 つのメッセージに様々なデータを詰め込む傾向があります。

その結果 1 つのメッセージは複雑かつデータ量が多いものになりがちです。

一方、実際のメッセージ交換では、メッセージの全てのデータを処理することはまれで一部のデータのみが必要となるケースがほとんどです。

皆さんこんにちは！ よろしければ、ボットが対話できるようになるようお手伝いいただけませんか？

チャットボットはこちらからアクセスしてください: Help my chatbots to talk!

なんだ、そのチャットボットはスマートではないのですか？

はじめに

ObjectScriptで複雑な問題を解決している場合、おそらく%Status値を使用したコードがたくさんあることでしょう。 オブジェクトの観点（%Save、%OpenIdなど）から永続クラスを操作したことがある場合は、ほぼ確実にその状況に遭遇したことがあるでしょう。 %StatusはInterSystemsのプラットフォームでローカライズ可能なエラーメッセージのラッパーを提供します。 OKステータス（$$$OK）は1に等しいだけであるのに対し、不良ステータス（$$$ERROR(errorcode,arguments...)）は0、スペース、エラーに関する構造化情報を含む$ListBuildリストとして表されます。 $System.Status（クラスリファレンスを参照）は、%Status値を操作するための便利なAPIをいくつか提供しています。クラスリファレンスを役立てられるので、ここでは繰り返しません。 このトピックに関する有用な記事/質問もほかにいくつかあります（最後のリンクをご覧ください）。 この記事では、コーディングのベストプラクティスではなく、いくつかのデバッグのコツや手法に焦点を当てています（ベストプラクティスについては、最後のリンクをご覧ください）。

背景

先日、ObjectScript の永続(Persistent)クラスのプロパティを編集していたところ、ストレージ定義が最後の変更を反映するように更新されていないことに気づきました。

この場合、クラス定義に不要となったプロパティを削除した上で保存し、再コンパイルしましたが、それでもストレージ定義に残ったままになっていました。

それでも焦ることはありませんでした。 ストレージ定義がコンパイル時に自動生成されるのであれば、それを削除して、クラスを再コンパイルすればよいからです。 もちろん、この後、削除されたプロパティはストレージ定義に表示されなくなりました。

問題解決... ですよね？

（ブブー、間違いです）

後になって、このアプローチはクラスにデータが保存されていないときに機能することがわかりました。 ただし、既存のデータがあるのであれば、重大なデータ参照の問題が発生する可能性があります。

そもそもストレージ定義とは？