在维护IRIS的镜像前，管理员需要清楚的了解以下一些概念：

Mirror的切换模式(failover mode)

切换模式在镜像监视器里被翻译成”故障转移模式“。 有两种模式：

• Agent Controlled模式：
• Arbiter Controlled模式：(页面上翻译为“仲裁程序受控制”)

通常情况，生产环境的镜像是安装了arbiter(仲裁者)的。Mirror启动时，在还没有连接上arbiter的时候，自动进入Agent-Controlled模式。而后当两台机器，主机，备机都连通了Arbiter，会保持在这个模式。

• 主备之间有连接；
• 又都连到arbiter;
• backup is active,

满足上面的条件，就进入arbiter controlled mode。而如果主备的任一方，失去了和arbiter的连接，或者备用侧丢了active, 开始尝试连接另一方，退回到agent-controlled模式。

Mirror同步成员的状态

Mirror Member Journal Transfer and Dejournaling Status. 请注意，这里面有两个概念：一个是Mirror成员的状态，一个是Journal传输和Dejournaling的状态。下面的图中是3个字段： STATUS, Journal传输，Dejournaling.

STATUS

镜像成员的状态。 正常工作状态

• 对于同步成员，是Primary(主)， Backup(备机)。

• 对于异步成员，正常状态是Connected(已连接)

• In Trouble : 如果主机In Trouble, 是失去了到backup的连接。备机收到主机的同步数据是要返回证实(Ack)消息的。一旦出现问题，主机无法收到备机的Ack， 主机就会把备机标为"In trouble", 从此再也不会向备机发同步数据。

• Transition: 暂时状态，进程正在查看一个成员的状态，很快会转换到一个稳定状态。 如果在mirror配置的member中发现了primary，本机会进入Synchronizing状态，否则自己会尝试进入primary状态。

• Sychronizing: 从Primary接收journal，同步数据库。

Journal Transfer and Dejournaling Status

Journal Transfer是主机向其他成员发送Journal文件。而Dejournal是把Journal文件读入数据库。 对于backup或者asycn成员，Journal Transfer状态表示镜像成员是否有来自主数据库的最新日志数据，如果没有，则表示日志传输的落后程度，Dejournaling表示从主数据库收到的所有日志数据是否已经被dejournaled（应用到成员的镜像数据库），如果没有，则表示dejournaling的落后程度。

上图中显示的是正常的状态，其中主机 Journal Transfer 和 Dejournaling 都是N/A, 表示不适用。

对于其他成员，我们分开看：

Journal Transfer状态

• Active: backup的正常状态。说明backup从primary收到了最新的journal。注意哪怕是Dejournal状态只是“x秒落后“，而不是"被捕获"，Journal Transfer状态也可以是Active，只要是从主机收到了最新的Journal更新。

• Caught up(被捕获) : 备机被捕获状态，说明备机从主机收到了最新的journal数据，但主机没有在等待备机的证实消息。 这通常是一个暂时的过程，当备机在连接主机的时候会出现。 异步成员，因为不需要向主机发证实，所以正常的状态就是“被捕获”

  If the Primary Failover Member does not receive an acknowledgment from the Backup every Heartbeat Interval period, it demotes the Backup system from Active status to Catch-Up mode.

• time behind (多少秒落后)

• Disconnected on time（断开）: 在一个时间点上这个成员和primary断开了。

Dejournaling状态

• Caught up
• time behind
• Disconnected on time
• Warning! Some Databases need attention
• Wanring! Dejournaling is stopped

正常状态下的图；

备机Backup MirrorB, Journal Transfer是Active, Dejournaling是Caught up, 异步机器MirrorDR的Journal Transfer状态和Dejournaling状态都是Caught up. 表示它们收到了最新的journal数据，并且也都把最新的global修改写入了自己的数据库。

Mirror的自动切换

Mirror的核心是自动切换。Backup接替主机的工作有两个前提：1. 备机在同步（Active) 状态, 2. 主机不能正常工作。在这两个前提下，我们来看看自动切换的触发条件，涉及主机，备机，仲裁机之间的通信，

自动切换触发条件

1. Primary要求Backup接替。这种情况，主机会发生一个请求消息给备机， 要求备机接替。

   • 主机IRIS正常退出
   • 主机发现自己hung

2. 备机收到arbiter的请求，报告失去了到主机的连接。

   仲裁机要求是和外部系统以及应用服务器部署在一个网段的。如果仲裁机无法联络主机，可以认为其他的应用系统和服务器也无法连接主机。有可能主机宕机， 也有可能主机还在正常工作，但外界已经无法联络它了， 这时候也是需要备机接手的。

   这时备机也要再去核实一下，是不是能联络到主机。如果能联络到， 备机会发请求让主机Down。如果不能， 说明主机要么死了， 要么失联了， 备机先接手，等联络上再让对方force down.

3. 从主机的ISCAgent收到消息，报告Primary已经down or hung.

   在agent-controlled的情况。 primary的服务器还活着。备机主动去问主机的agent, 一旦agent报告主机死了， 那备机就可以上位了。

Mirror的进程

管理员应该了解mirror涉及的那些进程。当出现故障时，这些进程名字，或者称为User， 经常会出现在message log记录的故障描述中。

On Primary Failover Member(主机)

我们来一个个的看看这些进程：

• Mirror Master: 系统启动时自动启动，负载mirror control 和管理。
• Mirror Primary: 出向数据传输通道。 上图中有两个Mirror Primary进程，状态时RUNW, 一个连接MirrorB, 一个连接MirrorDR.
• Mirror Svr: Rd*: 入向证实通道(inbound acknowledgement)， 也是单向的。 上图中同样有两个此进程，状态都是READ, IP地址分别是MirrorB和MirrorDR.
• Mirror Arbiter: 到aibiter的通信进程，注意它的状态是"EVTW", 也是个单向写的频道。

On Backup Member/Async member(备机)

Mirror Masht, Mirror Arbiter不再重复解释，我们看看其他进程是干什么的。

• Mirror JrnRead: Mirror Journal从Primary发送到backup是先写到硬盘的。 JrnRead进程把收到的journal同步读到内存里，然后才进行下一步，Dejournal的工作。

• Mirror Dejour: backup机器的dejournal job进程。它把从Primary收到的journal中记录的global改变(set and kill)保存到本机的镜像数据库。

• Mirror Prefetch: 这个稍微有点难懂。当收到的journal修改中包括了使用当前backup的journal中已有的内容时，比如收到了一个修改：set ^A=^B+1, 而^B当前存在backup里， Prefetch进程会把^B从硬盘拿到内存，以加快dejournal的速度。

• Mirror Backup: two-way channel， 把收到的primary的journal写到backup的mirror journal，并且返回证实(ACK)

这里我省略了在DR上的进程，如果有兴趣，请自己查看文档。

MIRROR状态的监控

根据不同的场景，查看Mirror的状态有以下几种途径

使用镜像监视器

使用^MIRROR

如果您只是要简单的获得Mirror成员的状态，最直接的方法是使用^Mirror程序。 我们先看看在IRIS Terminal下^MIRROR的执行。

%SYS>do ^MIRROR


1) Mirror Status
2) Mirror Management
3) Mirror Configuration

Option? 1

1) List mirrored databases
2) Display mirror status of this node
3) Display journal file info
4) Status Monitor

Option? 4
Status of Mirror MIRRORTEST at 08:09:24 on 05/19/2023
Arbiter Connection Status:
     Arbiter Address:   arbiter|2188
     Failover Mode:     Agent Controlled
     Connection Status: This member is not connected to the arbiter

                                       Journal Transfer
Member Name+Type            Status        Latency       Dejournal Latency
--------------------------  ---------  ---------------  --------------
MIRRORA
     Failover               Primary    N/A              N/A

Press RETURN to refresh, D to toggle database display, Q to quit,
 or specify new refresh interval <60> D
Database display is now on


Status of Mirror MIRRORTEST at 08:09:29 on 05/19/2023
Arbiter Connection Status:
     Arbiter Address:   arbiter|2188
     Failover Mode:     Agent Controlled
     Connection Status: This member is not connected to the arbiter

                                       Journal Transfer
Member Name+Type            Status        Latency       Dejournal Latency
--------------------------  ---------  ---------------  --------------
MIRRORA
     Failover               Primary    N/A              N/A

Mirror Databases:
                                                                   Record To
Name           Directory path                          Status      Dejournal
-------------  -----------------------------------     ----------- -----------
TEST           /isc/mirrorA/TESTDB/                    Normal      N/A


Press RETURN to refresh, D to toggle database display, Q to quit,
 or specify new refresh interval <60>

在操作系统中执行^MIRROR

您可以把以下的代码写入您的脚本语言，查看mirror的状态

irisowner@mirrorA:~$ iris session iris -U "%sys" "Monitor^MIRROR"

Status of Mirror MIRRORTEST at 02:57:08 on 06/13/2023
Arbiter Connection Status:
     Arbiter Address:   arbiter|2188
     Failover Mode:     Arbiter Controlled
     Connection Status: Both failover members are connected to the arbiter

                                       Journal Transfer
Member Name+Type            Status        Latency       Dejournal Latency
--------------------------  ---------  ---------------  --------------
MIRRORA
     Failover               Primary    N/A              N/A
MIRRORB
     Failover               Backup     Active           Caught up
MIRRORDR
     Disaster Recovery      Connected  Caught up        Caught up

Press RETURN to refresh, D to toggle database display, Q to quit,
 or specify new refresh interval <60>q
Doneirisowner@mirrorA:~$

或者更简单的，只查看本机的mirror成员状态：

irisowner@mirrorA:~$ iris session iris -U "%sys" "LocalMirrorStatus^MIRROR"

This instance is a Failover member
     Status for mirror MIRRORTEST is "Primary"

Current mirror file #2 ends at 681224
Min trans file #2 min trans index: 680744
irisowner@mirrorA:~$

如果您熟悉ObjectScript， 也可以使用$SYSTEM.Mirror类的各个method来查看：

irisowner@mirrorB:~$ echo "write \$SYSTEM.Mirror.GetMemberStatus(),! halt" |iris session iris -U "%sys"

Node: mirrorB, Instance: IRIS
%SYS>
Backup
irisowner@mirrorB:~$

如果您要查看更多的内容，您可以更多的使用%SYSTEM.Mirror类的其他方法，比如%SYSTEM.Mirror.GetFailoverMemberStatus(.pri,.alt)， $SYSTEM.Mirror.ArbiterState()等等。

使用Mirror_MemberStatusList存储过程

如果您从第3方的工具查询mirror成员的状态，还有一个简单的方案，就是调用%SYS命名空间的存储过程。下图是从iris管理门户调用的截图，你可以使用任何SQL客户端调用。

如果是从iris里执行，

%SYS>do ##class(%ResultSet).RunQuery("SYS.Mirror","MemberStatusList")

Member Name:Current Role:Current Status:Journal Transfer Latency:Dejournal Latency:Journal Transfer Latency:Dejournal Latency:Display Type:Display Status:
MDCHCNDBSL1.HICGRP.COM/STAGE:Primary:Active:N/A:N/A:N/A:N/A:Failover:Primary:
MDCHCNDBSL2.HICGRP.COM/STAGE:Backup:Active:Active:Caught up:Active:Caught up:Failover:Backup:
CDCHCNDRSL.HICGRP.COM/STAGE:Async:Async:Caught up:Caught up:Caught up:Caught up:Disaster Recovery:Connected:

通过SNMP获得

如果使用监控工具，您可以通过SNMP获得Mirror的状态，下面是最新的ISC-IRIS.mib中有关Mirror得指标部分。

.4.1.12 = irisMirrorTab | Table of current Mirror Members status and information
-- .4.1.12.1 = irisMirrorRow | Conceptual row for Mirror status and metrics | INDEX = irisSysIndex, irisMirrorIndex
-- .4.1.12.1.1 = irisMirrorIndex | unique index for each Mirror Member | INTEGER
-- .4.1.12.1.2 = irisMirrorName | Name of the mirror this system is a member of | STRING
-- .4.1.12.1.3 = irisMirrorMember | Mirror member name | STRING
-- .4.1.12.1.4 = irisMirrorRole | "Primary", "Backup", or "Async". | STRING
-- .4.1.12.1.5 = irisMirrorStatus | "Active" or "Activate". | STRING
-- .4.1.12.1.6 = irisMirrorJrnLatency | Mirror journal latency "Caught up", "Catchup", or "N/A". | STRING
-- .4.1.12.1.7 = irisMirrorDBLatency | Mirror database latency "Caught up", "Catchup", or "N/A". | STRING

MIRROR的日志和告警

通常情况下， 维护人员是通过mirror的日志和警告来获得Mirror状态，Mirror成员之间的连接情况，而不必须定时的用命令或者调用存储过程来查看。

Cache'和IRIS的日志和警告保存在两个文件： console.log/messages.log和alert.log， 其中alert.log中记录了console.log/messages.log中级别为2，3的记录， 并必须实时发送给管理员。有关这部分内容，请参考在线文档，或者我的帖子：

我们来看看在日志中有哪些mirror的记录：

Becoming primary mirror server

系统固有的通知消息， level =2。当一个iris实例从备机变成了主机，此信息会写到此实例的alert.log, 同时发送给管理员。 可以查看这个链接。

在Mirror切换时，管理员除了从刚刚接手的机器中收到Becoming primary mirror server的通知。如果原来的主机没有宕机或者从宕机中恢复，它也会将引起切换的故障从alert.log发送给管理员，是一个level2, 或者level3的记录。

Arbiter connection lost

level =2 , 自动发送给管理员。 当主机和arbiter失去连接后，在主机上会出现此警告。此时在备机上会出现“Switched from Arbiter Controlled to Agent Controlled failover on request from primary”的提示，是个level0的信息。

MirrorServer: Connection to xxxx(backup) terminatedMirrorServer: Connection to MIRRORDR (async member) terminated

当主机和备机(backup)失去连接，在主机上会出现level2的警告。 而和异步成员丢失连接，主机会出现level1的消息。尽管level1的消息不能自动通知管理员，但这时如果同时监控该异步成员的alert.log, 通常会有level2的警告消息发出，能提醒管理员检查MIRRORDR这个镜像成员的状态。

举例说明：如果在MirrorDR中操作系统重启，IRIS启动后会出现这样的level2的警告：“Previous system shutdown was abnormal, ^SHUTDOWN forced down”

Async member for MirrorSetName started but failed to connect to primary

level =2 , 自动发送给管理员

其他更多的关于Mirror出错的level2, 也就是警告记录, 比如：

• Could not open mirror journal log to read checksum, errno = 2
• Preserving all mirror journal files for offline failover member
• Server^MIRRORCOMM(d): Failed to notify MIRRORB for mirror configuration change
• Failed to become either Primary or Backup at startup

这不是个完整的列表，实际环境中会出现各种各样的告警通知。读懂这些通知，需要管理员了解镜像的原理，架构，以及上面介绍的镜像状态和进程的功能。

除此之外，绝大多数的level2日志的同时，会有更多的level0,level1的有关mirror变化的记录。这些内容不需要通知管理员，只是用于分析问题。 如图，下面是在一个messages.log里一个iris从备机变成主机的过程。

06/13/23-07:16:25:472 (2189) 0 [Generic.Event] MirrorClient: Switched from Arbiter Controlled to Agent Controlled failover on request from primary
06/13/23-07:16:26:274 (2189) 1 [Generic.Event] MirrorClient: Mirror_Client: Primary closed down, last # read = 504
06/13/23-07:16:26:301 (2189) 0 [Generic.Event] MirrorClient: Backup waiting for old Dejournal Reader (pid: 2190, job #31) to exit
06/13/23-07:16:27:394 (2189) 0 [Generic.Event] MirrorClient: Set status for MIRRORTEST to Transition
06/13/23-07:16:28:477 (1996) 0 [Utility.Event] [SYSTEM MONITOR] Mirror status changed. Member type = Failover, Status = Transition
06/13/23-07:16:30:261 (2177) 0 [Utility.Event] Returning to restart, old primary reported: "DOWN
06/13/23-07:16:31:524 (11721) 0 [Utility.Event] Applying journal data for mirror "MIRRORTEST" starting at 1538184 in file #2(/isc/mirrorB/mgr/journal/MIRROR-MIRRORTEST-20230613.001)
06/13/23-07:16:31:804 (2177) 0 [Utility.Event] Manager initialized for MIRRORTEST
06/13/23-07:16:31:986 (2177) 0 [Utility.Event] MIRRORA reports it is DOWN, becoming primary mirror server
06/13/23-07:16:32:381 (2177) 0 [Generic.Event] INTERSYSTEMS IRIS JOURNALING SYSTEM MESSAGE
Journaling switched to: /isc/mirrorB/mgr/journal/MIRROR-MIRRORTEST-20230613.002
06/13/23-07:16:32:426 (2177) 0 [Utility.Event]   Scanning /isc/mirrorB/mgr/journal/MIRROR-MIRRORTEST-20230613.001
06/13/23-07:16:32:479 (2177) 0 [Utility.Event] No open transactions to roll back
06/13/23-07:16:32:485 (2177) 0 [Generic.Event] MirrorServer: New primary activating databases which are current as of 1538184 (0x00177888) in mirror journal file #2
06/13/23-07:16:32:488 (2177) 0 [Generic.Event] Changed database /isc/mirrorB/TESTDB/ (SFN 5) to read-write due to becoming primary.
06/13/23-07:16:32:924 (2177) 0 [Utility.Event] Initializing Interoperability during mirror initialization
06/13/23-07:16:32:930 (2177) 2 [Utility.Event] Becoming primary mirror server

更多的有关mirror监控和排除的问题， 请各位留言。 谢谢

第二十九章 开发Productions - ObjectScript Productions - 定义业务操作 - 定义消息处理程序方法

定义消息处理程序方法

当创建业务操作类时，通常最大的任务是编写用于此适配器的消息处理程序，即接收生产消息的方法，然后调用适配器的方法以便与生产之外的目标进行通信。

每个消息处理程序方法都应具有以下签名：

Method Sample(pReq As RequestClass, Output pResp As ResponseClass) As %Status

这里Sample是方法名，RequestClass是请求消息类名，ResponseClass是响应消息类名。

通常，该方法应执行以下部分或全部操作：

1. 可选地设置业务操作类的属性（在任何适当的时间）。请参阅业务运营属性。
2. 检查输入对象。
3. 创建响应类的实例。
4. 调用适配器的适用方法。这些方法可通过业务操作的 Adapter 属性使用。例如：

    Set tSc=..Adapter.SendMail(email,.pf)

在这些步骤之后讨论此方法。

或者，要将消息发送到Productions中的目标，请参阅将消息发送到Productions中的目标。

5. 检查响应。
6. 使用响应中的信息创建响应消息（Ens.Response 在的实例），该方法将其作为输出返回。
7. 确保设置输出参数 (pOutput)。通常，将其设置为等于响应消息。此步骤是必需的。
8. 返回适当的状态。此步骤是必需的。

业务操作属性

在操作方法中，业务操作类的以下属性可用：

嗨社区！

想与您分享我在Telegram中使用GPT创建“我自己的”聊天的练习。

这个应用需要用到 Open Exchange 上的两个组件：@Nikolay Solovyev 的Telegram Adapter和@Kurro Lopez的IRIS Open-AI 

因此，通过此示例，您可以在 Telegram 中使用 ChatGPT 设置自己的聊天。

让我们看看如何让它发挥作用！

如果您已经使用%UnitTest 框架构建了单元测试，或者正在考虑这样做，请查看InterSystems 测试管理器Test Manager。

无需离开 VS Code，您现在可以浏览单元测试、运行或调试它们，并查看之前的运行结果。

InterSystems 测试管理器适用于 ObjectScript 扩展支持的两种源代码位置范例。您的单元测试类可以在 VS Code 的本地文件系统（“客户端编辑”范例）或服务器命名空间（“服务器端编辑”）中掌握。在这两种情况下，实际测试运行都发生在服务器命名空间中。

欢迎反馈。

当数据资产已经成为医院的核心资产，如何有效利用数据核心资产，持续挖掘互联互通平台和各种数据中心的价值，成为医疗信息化工作的重中之重。欢迎扫码注册（或点击链接注册）观看多位大咖针对这一话题的解读。

第二十七章 开发Productions - ObjectScript Productions - 定义业务流程 - 关键原则

关键原则

在开发业务流程时，请考虑以下关键原则：

• 有时希望使响应对象成为传入请求对象的修改版本，分阶段进行修改可能很有用。但是，不要修改传入的请求对象。而是将其复制到上下文变量（或者，对于自定义业务流程，将数据复制到局部变量）。然后修改副本。
• 同步发送消息时要小心（只能在自定义业务流程中或 BPL 中的 <code>中执行）。

当业务流程A同步调用业务流程B时，流程A不会继续，直到收到响应。如果进程 A 需要完成对其他进程 (B) 的调用才能完成自身，并且如果这些进程共享参与者作业池，则如果没有空闲的参与者作业来处理被调用的业务流程，则参与者池可能会陷入死锁（ B).

发生这种情况是因为在被调用业务流程返回之前，调用业务流程无法完成并释放参与者作业，但被调用业务流程无法执行，因为没有空闲的参与者作业来执行它。

另请注意， IRIS 无法在真正的同步调用期间关闭。

最好使用 SendRequestAsync() 并在 OnResponse() 方法中处理响应消息。如果需要同步调用，可以通过配置被调用的业务流程（B）使用自己的作业池来避免这个问题。

• 如果单一作业业务流程发出请求并等待响应，则该流程将失去 FIFO 功能。

因为来自 BPL 的同步调用是由编译器异步实现的，所以业务流程将在发出调用后转到磁盘。然后，参与者可以继续使新的业务流程或对其他业务流程的响应出队。

如果没有发出需要响应的调用请求，则仅保证单个作业业务流程的 FIFO 处理。如果业务流程必须进行调用并仍保持 FIFO，则它必须使用调用 SendRequestSync() 的 <code> 活动。但是，在这种情况下，前面的项目符号项目适用。

• BPL 提供了一个有用的优势：它以流线型和优雅的方式处理同步和异步消息传递的各个方面，从而防止常见的争用和死锁问题。即使调用被标记为同步，如果需要任何等待时间，生产框架也会安静地释放代表 BPL 业务流程执行调用的作业，以便它可以在 BPL 等待同步响应时执行其他工作。稍后，框架静默协调同步响应的接收并唤醒 BPL 业务流程以恢复其工作。

如果使用自定义代码，很容易（不小心）设计出容易出现死锁的产品。需要做的就是创建一系列发送同步请求并使用有限参与者池的业务流程。如果 production 随后接收到与 actor 相同数量的消息，并且所有消息同时发生同步发送，则 production 最终陷入死锁，所有 actor 进程都处于等待另一个进程从队列中释放消息的状态.此问题最危险的方面是测试不一定会产生导致死锁的条件。很有可能在部署后首先遇到死锁。目前尚不清楚生产中断的原因，而且这一不可预见的问题的成本可能很高。

定义 BPL 业务流程

BPL 业务流程是基于 Ens.BusinessProcessBPL的类。在这种情况下，可以在管理门户或 IDE 中可视化地创建和编辑流程。有关信息，请参阅开发 BPL 流程。

定义自定义业务流程

要创建自定义业务流程类，请按如下方式定义一个类：

• 类必须在（或子类）中扩展 Ens.BusinessProcess。
• 类必须实现 OnRequest() 和 OnResponse() 方法，如下两节所述。
• 班级可以添加或删除设置。请参阅添加和删除设置。
• 类可以实现任何或所有启动和拆卸方法。请参阅覆盖启动和停止行为。
• 类可以包含完成自身内部工作的方法。

实现 OnRequest() 方法

自定义业务流程类必须实现 OnRequest() 方法。每当对特定业务流程的初始请求到达适当的队列并分配一个要执行的作业时，生产就会调用此方法。

此方法具有以下签名：

method OnRequest(request As %Library.Persistent, Output response As %Library.Persistent) as %Status

• request — 传入的请求对象。
• response — 此业务流程返回的响应。

示例

以下是 OnRequest() 方法的示例：

Method OnRequest(request As Demo.Loan.Msg.Application, Output response As Demo.Loan.Msg.Approval)
       As %Status
{
  Set tSC=$$$OK
  $$$TRACE("received application for "_request.Name)
    #;
  If $zcrc(request.Name,2)#5=0 {
    Set tRequest = ##class(Demo.Loan.Msg.PrimeRateRequest).%New()
    Set tSC =..SendRequestAsync("Demo.Loan.WebOperations",tRequest,1,"PrimeRate")
    If $$$ISOK(tSC){
      Set tRequest = ##class(Demo.Loan.Msg.CreditRatingRequest).%New()
      Set tRequest.SSN = request.SSN
      Set tSC =..SendRequestAsync("Demo.Loan.WebOperations",tRequest,1,"CreditRating")
      If $$$ISOK(tSC){
        Set tSC = ..SetTimer("PT15S")
      }
    }
  } Else {
      Set response = ##class(Demo.Loan.Msg.Approval).%New()
      Set response.BankName = "BankUS"
      Set response.IsApproved = 0
      $$$TRACE("application is denied because of bank holiday")
    }
  Return tSC
}

实施 OnResponse() 方法

自定义业务流程类必须实现 OnResponse() 方法。每当特定业务流程的响应到达适当的队列并分配一个要执行的作业时，生产就会调用此方法。通常，这是对业务流程发出的异步请求的响应。

method OnResponse(request As %Library.Persistent,
                  ByRef response As %Library.Persistent,
                  callrequest As %Library.Persistent,
                  callresponse As %Library.Persistent,
                  pCompletionKey As %String) as %Status

• request — 发送到此业务流程的初始请求对象。
• response — 此业务流程最终将返回的响应对象。
• callrequest — 与传入响应关联的请求对象。
• callresponse — 传入响应对象。
• pCompletionKey — 与传入响应关联的完成键值。这是通过调用发出请求的 SendRequestAsync() 方法设置的。

示例

以下是 OnResponse() 方法的示例：

/// Handle a 'Response'
Method OnResponse(request As Ens.Request,
                  ByRef response As Ens.Response,
                  callrequest As Ens.Request,
                  callresponse As Ens.Response,
                  pCompletionKey As %String) As %Status
{
    Set tSC=$$$OK
    If pCompletionKey="PrimeRate" {
        Set ..PrimeRate = callresponse.PrimeRate
    } Elseif pCompletionKey="CreditRating" {
        Set ..CreditRating = callresponse.CreditRating
    }
    Return tSC
}

在 OnRequest() 和 OnResponse() 中使用的方法

• SendDeferredResponse()
• SendRequestSync()
• SendRequestAsync()
• SetTimer()
• IsComponent()

第二十四章 开发Productions - ObjectScript Productions - 定义业务服务

本页介绍如何定义业务服务类。

提示： IRIS® 提供使用特定入站适配器的专用业务服务类，其中之一可能适合需要。如果是这样，则不需要编程。有关部分列表，请参阅 Introducing Interoperability Productions 中的连接选项。

介绍

业务服务负责接受来自外部应用程序的请求到 IRIS。下图显示了它是如何工作的：

请注意，此图仅显示数据的输入流，而不是可选响应。

业务服务负责以下活动：

• 等待特定的外部事件（例如来自应用程序的通知、收到 TCP 消息等）。
• 读取、解析和验证伴随此类事件的数据，
• 如果需要，返回对外部应用程序的确认，表明已收到事件。
• 创建请求消息的实例并将其转发到适当的业务流程或业务操作以进行处理。

业务服务的目的通常是接收数据输入。在大多数情况下，业务服务有一个与之关联的入站适配器。但是，在某些情况下不需要适配器，因为应用程序能够将请求消息发送到服务中，或者因为业务服务已被编写为处理特定类型的外部调用，例如来自复合应用程序的调用。这种类型的业务服务称为无适配器业务服务。

当业务服务具有入站适配器时，它处于数据拉取（而不是推送）模式。在这种模式下，业务服务会定期轮询适配器，看它是否有数据。同时，如果适配器随时遇到输入数据，它会调用业务服务来处理输入。

当业务服务没有适配器时，它不会拉取数据。相反，客户端应用程序调用业务服务并告诉它处理输入（这是一种数据推送模式）。

关键原则

首先，务必阅读 Programming in InterSystems IRIS。

在业务服务中，可以访问关联适配器的属性和方法，这些适配器作为业务服务的 Adapter 属性提供。这意味着可以更改适配器的默认行为；这样做可能合适也可能不合适。记住封装原则很有用。封装的思想是适配器类应该负责技术特定的逻辑，而业务服务类应该负责生产特定的逻辑。

如果发现有必要在业务服务类中大量或频繁地改变适配器类的行为，那么创建适配器类的自定义子类可能更合适。请参阅不太常见的任务。

这个原则也适用于商业运作。

定义业务服务类

要创建一个业务服务类，定义一个类如下：

• 类必须在（或子类）中扩展 Ens.BusinessService。
• 在类中，ADAPTER 参数必须等于此业务服务要使用的适配器类的名称。

提示：如果只是希望业务服务定期唤醒和运行而不关心 IRIS 外部的事件，请使用适配器类 Ens.InboundAdapter。

• 类必须实现 OnProcessInput() 方法，如实现 OnProcessInput() 方法中所述。
• 类可以添加或删除设置。请参阅添加和删除设置。
• 类可以实现任何或所有启动和拆卸方法。请参阅覆盖启动和停止行为。
• 类可以包含完成自身内部工作的方法。

有关业务服务类的示例，请参阅适配器指南。

实施 OnProcessInput() 方法

在业务服务类中， OnProcessInput() 方法可以具有以下通用签名：

Method OnProcessInput(pInput As %RegisteredObject, pOutput As %RegisteredObject) As %Status

这里的pInput是适配器要发送给这个业务服务的输入对象，pOutput是输出对象。

首先查看选择的适配器类。 建议编辑 OnProcessInput() 方法签名以使用适配器所需的特定输入参数。

OnProcessInput() 方法应该执行以下部分或全部操作：

1. 可选地设置业务服务类的属性（在任何适当的时间）。最受关注的业务服务属性是 %WaitForNextCallInterval。它的值控制 IRIS 调用适配器的 OnTask() 方法的频率。

有关其他属性，请参阅 Ens.BusinessService的类参考。

2. 如有必要，验证输入对象。
3. 检查输入对象并决定如何使用它。
4. 创建请求消息类的实例，这将是业务服务发送的消息。
5. 对于请求消息，使用输入对象中的值适当地设置其属性。
6. 确定要将请求消息发送到哪里。当发送消息时，将需要在生产中使用业务主机的配置名称。
7. 将请求消息发送到生产（业务流程或业务操作）中的目的地。请参阅下一节。
8. 确保设置输出参数 (pOutput)。通常，将其设置为等于您收到的响应消息。此步骤是必需的。
9. 返回适当的状态。此步骤是必需的。

InterSystems 支持的硬件OS平台更新 2023年2季度

我们经常收到有关 InterSystems IRIS 数据平台支持的平台和框架列表最近和即将发生的变化的问题。此更新旨在分享最近的更改以及我们对即将发生的更改的已知的情况，但预测未来是一项棘手的工作，不应将其视为承诺的路线图。

话虽如此，关于更新……

IRIS 生产操作系统和 CPU 架构

红帽企业 Linux

Hi 开发者们！一年一度的 InterSystems IRIS 开发者大奖赛已启动！

我们非常高兴地邀请大家参加此次编程大赛——使用 InterSystems IRIS 数据平台构建开源解决方案！

🏆 InterSystems 2023 年度编程大奖赛🏆

时间： 2023年6月12日-7月9日（美国东部时间）

奖金池： 26,000 美元

第二十一章 开发Productions - ObjectScript Productions - 延迟发送

延迟发送

除了同步（等待）和异步（不等待）的直接选择之外，还可以使用称为延迟响应的机制在 IRIS 之外发送消息。

假设一个业务流程希望在 IRIS 之外调用一个动作。它向业务操作发送请求，业务操作执行调用并返回响应。业务流程是任何响应的预期接收者；业务操作只是请求发出和响应进来的方式。如果业务流程同步发出请求，或者如果它发出请求并请求异步响应，业务操作将中继回响应。下图总结了这种机制。

现在假设从业务流程接收请求的业务操作已被编写为使用延迟响应功能。原始发件人不知道响应将被业务操作延迟这一事实。延迟响应是业务运营开发人员做出的设计决策。如果业务操作确实延迟了响应，那么当原始发送者在延迟期结束时收到响应时，它不知道响应曾经被延迟过。

业务操作通过调用其 DeferResponse() 方法来生成表示原始发送者和原始请求的令牌来延迟响应。业务运营还必须找到一种方法将此令牌传达给外部实体，然后外部实体负责将此令牌包含在对 IRIS 的任何后续响应中。例如，如果外部目的地是电子邮件，业务操作可以在外发电子邮件的主题行中包含令牌字符串。接收此电子邮件的实体可以从请求主题行中提取此令牌，并在响应主题行中使用它。在下图中，项目 t 代表此令牌。

从业务操作延迟请求到原始发送者最终收到响应之间，请求消息的状态为 Deferred。原发送方收到相应响应后，请求消息状态由Deferred变为Completed。

Productions中的任何业务主机都可以拾取响应请求的传入事件并将其返回给原始发送者。事件在 IRISProductions中到达的确切位置取决于Productions的设计；通常，业务服务的任务是接收来自 IRIS 外部的传入事件。接收传入事件的业务主机还必须随事件一起接收延迟响应令牌。然后，业务主机调用其 SendDeferredResponse() 方法，根据传入的事件数据创建适当的响应消息，并将此响应定向到原始发件人。原始发件人在不知道响应如何返回的情况下收到响应。下图显示了一个请求及其延迟响应。

生成事件日志条目

事件日志是一个表，记录在给定名称空间中运行的生产中发生的事件。 Management Portal 提供了一个显示此日志的页面，它主要供系统管理员使用，但在开发过程中也很有用。 （有关此页面的详细信息，请参阅监控制作。）

事件日志的主要目的是提供诊断信息，在生产运行时出现问题时，这些信息对系统管理员很有用。

IRIS 自动生成事件日志条目，可以添加自己的条目。任何给定事件都是以下类型之一：断言、信息、警告、错误和状态。 （事件日志还可以包括警报消息和跟踪项，将在下一节中讨论。）

要生成事件日志条目：

1. 确定要记录的事件。

并非所有类型的错误或活动都必须生成事件日志条目。必须选择要记录的事件、要使用的类型以及要记录的信息。例如，事件日志条目应在出现外部物理问题（如网络连接不良）时出现。

事件日志不应记录程序错误；这些应该在产品发布之前解决。

2. 修改Productions的适用部分（通常是业务主机类）以在 ObjectScript 中生成事件日志条目，如以下小节所述。

重要提示：如果需要主动通知用户某些情况或事件，请使用警报，这将在下一节和定义警报处理器中讨论。

在 ObjectScript 中生成事件日志条目

在业务主机类或产品使用的其他代码中，可以在 ObjectScript 中生成事件日志条目。为此，请使用以下任一宏。这些宏在 Ensemble.inc 包含文件中定义，该文件自动包含在 IRIS 系统类中：

下面显示了一个示例，其中包含将静态文本与类属性值组合在一起的表达式：

 $$$LOGERROR("Awaiting connect on port "_..Port_" with timeout "_..CallInterval)

以下示例使用 ObjectScript 函数：

 $$$LOGINFO("Got data chunk, size="_$length(data)_"/"_tChunkSize)

第二十章 开发Productions - ObjectScript Productions - 指定设置的默认值

当定义业务主机类（可能还有适配器类）时，应该考虑如何控制这些项目的任何设置的默认值。 IRIS 可以从三个来源之一获取设置的默认值：

• production定义。
• 为 IRIS 实例定义的值，但存储在production定义之外。有关信息，请参阅配置制作中的定义制作默认值。
• 主机类中定义的属性的默认值。在这种情况下，默认值由 InitialExpression 属性关键字确定。

某些设置取决于环境，例如 TCP/IP 地址或文件路径；通常，将这些设置配置为在生产之外提供它们的源，而其他设置（例如 ReplyCodeActions）是设计决策，并且很可能开发应用程序以从生产定义中检索这些设置。

可以开发作品，使配置设置来自不同的来源。主要目的是更轻松地将制作从一个 IRIS 实例转移到另一个实例，例如从测试转移到现场。

定义生产后，可以在管理门户的生产配置页面上更改生产和业务主机设置的来源。有关详细信息，请参阅配置制作。

默认设置的使用允许在Productions定义之外定义Productions和业务主机设置，可以在生产升级期间保留它们。为了便于更新产品或将产品从一个系统移动到另一个系统，可以省略设置并从系统上安装的结构中获取它们的值。当设置缺失时， IRIS 会从生产定义之外检索默认设置（如果存在的话）。

有关编程详细信息，请参阅类参考的 Ens.Director类条目中对以下方法的描述：

• GetProductionSettingValue()

• GetProductionSettings()

从业务主机访问属性和方法

在业务宿主类中定义方法时，可能需要访问该类或关联适配器的属性或方法。本节简要描述了如何做这些事情。

在业务主机的实例方法中，可以使用以下语法：

• ..bushostproperty

访问业务主机的设置或任何其他属性。 （请记住，所有设置都是其各自类的属性。）

• ..bushostmethod()

访问业务宿主的实例方法。

• ..Adapter.adapterproperty

访问适配器的设置或任何其他属性。 （请注意，每个业务主机都有 Adapter 属性。使用该属性访问适配器，然后使用点语法访问适配器的属性。）

• ..Adapter.adaptermethod()

访问适配器的实例方法，将参数传递给该方法。例如，要从业务操作中调用出站适配器的 PutStream 方法，请输入：

..Adapter.PutStream(pFilename,..%TempStream)

访问Production设置

可能需要访问制作的设置。为此，请使用宏 $$$ConfigProdSetting。例如，$$$ConfigProdSetting("mySetting")检索名为 mySetting 的生产设置的值。 建议将此宏包装在 $GET 调用中以确保安全；例如：

选择如何发送消息

在业务运营和业务流程中，方法通常会调用继承的方法来将消息发送到生产中的其他业务主机。本节讨论这些选项。

同步和异步发送

当定义业务服务、业务流程和业务操作类时，指定如何从该业务主机发送请求消息。有两个主要选项：

• 同步 — 调用者停止所有处理以等待响应。
• 异步——调用者不等待；发送请求后，调用者立即恢复其他处理。异步发送请求时，调用者指定关于响应此请求的两个选项之一：
  • 要求在回复到达时收到回复。
  • 忽略响应的可能性。

如何发送消息的选择没有记录在消息本身中，也不是消息定义的一部分。相反，这由发送消息的业务主机类决定。

Manifest也许应该被翻译成“清单”， 字典上是这么解释的： 提供船舶及其货物和其他物品、乘客和船员的全面细节的文件，供海关官员使用，比如：飞机上的乘客或货物清单； 一辆货运列车的车厢清单。

在计算机语言中， Manifest可以是各种格式，用的最多的是xml和json，在IRIS中，manifest是xml格式的， 放在objectscript类的XDATA块里。

编写mainfest

IRIS用manifest来做配置。内部工具*%install*, 会读取manifest, 生成真正的objectscript代码来配置IRIS。我们来看个基本的例子。

基本用法

下面的User.Manifest.cls` ,它配置了IRIS的global buff, bbsize等等, 然后还创建了一个命名空间。

Include %occInclude
Class User.Manifest
{

ClassMethod setup(ByRef pVars, pLogLevel As %Integer = 3, pInstaller As %Installer.Installer, pLogger As %Installer.AbstractLogger) As %Status [ CodeMode = objectgenerator, Internal ]
{      
   Quit ##class(%Installer.Manifest).%Generate(%compiledclass, %code, "MyInstall")
}

XData MyInstall [ XMLNamespace = INSTALLER ]{
<Manifest>
	<SystemSetting Name="Config.config.gmheap" Value="50000"/>
   <SystemSetting Name="Config.config.locksiz" Value="5000000"/>
   <SystemSetting Name="Config.config.routines" Value="256"/>
   <SystemSetting Name="Config.config.globals8kb" Value="600"/>
   <SystemSetting Name="Config.config.wijdir" Value="/cache/wij"/>
   <SystemSetting Name="Config.Journal.CurrentDirectory" Value="/journal1"/>
   <SystemSetting Name="Config.Journal.AlternateDirectory" Value="/journal2"/>
   <SystemSetting Name="Config.Miscellaneous.EnableLongStrings" Value="1"/>
   <Namespace Name="TUOTANTO" Create="yes" Code="TUOTANTO-R" Data="TUOTANTO-D">
   	<Configuration>
    		<Database Name="TUOTANTO-R" Create="yes" Dir="/cache/database/TUOTANTO-R"/>
    		<Database Name="TUOTANTO-D" Create="yes" Dir="/cache/database/TUOTANTO-D"/>
    	</Configuration> 
    </Namespace>   
</Manifest>
}
}

稍微解释一下代码：

• Include %occInclude是必须的

• setup()用来读取manifest的内容，完成配置工作。用户基本不用修改这个method。

• mainifest本身的逻辑层次很清楚，要配置什么内容查查文档都可以。上面的manifest只是个示意，真正用起来可以需要非常多的配置项，比如namespace, database的配置，有很多的标签可选。

传参数给manifest

调用manifest的method, 也就是例子里的setup(), 注意第一个参数是ByRef pVars。这是objectscript里常用的By referrence的传参方式。请看下面的例子：

Include %occInclude
Class User.Manifest
{

ClassMethod main(){
   Set pVars("Namespace")="MYNAMESPACE"
   Set pVars("AnotherKey")= "AnotherValue"
   $$$ThrowOnError(..CreateNamespace(.pVars))
}

ClassMethod CreateNamespace(ByRef pVars, pLogLevel As %Integer = 3, pInstaller As %Installer.Installer, pLogger As %Installer.AbstractLogger) As %Status [ CodeMode = objectgenerator, Internal ]{      
   Quit ##class(%Installer.Manifest).%Generate(%compiledclass, %code, "CreateNamespace")
}

XData CreateNamespace [ XMLNamespace = INSTALLER ]{
<Manifest>
	<Log Text="This is the content of ${AnotherKey}" Level="0" />
   <Namespace Name="${Namespace}" Create="yes" Code="${Namespace}" Data="${Namespace}" Ensemble="1">
		<Configuration>
			<Database Name="${Namespace}" Create="yes" Dir="${MGRDIR}/${Namespace}" Resource="%DB_${Namespace}" PublicPermissions="RW" MountAtStartup="true" />
		</Configuration>	
	</Namespace>
</Manifest>
}
}

上面code在main()里定义了一个pVars, 放了两个key-value， 用来调用CreateName()。 定义的namespace在manifest用到了， Anotherkey被用在了log里， 只是一个示意。

注意这个定义： Dir="${MGRDIR}/${Namespace}"。 其中的MGRDIR不需要自己定义。Manifest有一堆自己定义的Variable, 用的最多的是 CFGDIR, CSPDIR, INSTALLDIR, MGRDIR, PORT等等。具体列表见文档。

更多的用法

下面这个例子包括了import文件和copy文件, SourceDir和Namespace是传入的参数。导入文件要在一个namespace的定义里面, 拷贝文件和命名空间无关。

<Manifest>	
   <Namespace Name="${Namespace}">
		<Import File="${SourceDir}/code.xml" Flags="ck" Recurse="1"/>
	</Namespace>
   <CopyDir Src="${SourceDir}/xslfiles" Target="${CSPDIR}/xslt" IgnoreErrors="0"/>
   <CopyFile Src="${SourceDir}/a.html" Target="${CSPDIR}/hcc" IgnoreErrors="0"/>
</Manifest>

CSPApplication

在manifest里定义cspapplication不难，麻烦的是不同的版本使用的标签上会有修改。下面给了一个例子。

<Manifest>
	<Namespace Name="flagger">
      <CSPApplication CSPZENEnabled="1" LoginClass="/csp/flagger/Flagger.LoginAuth.cls" CustomErrorPage="/csperror.csp" ChangePasswordPage="/csp/flagger/ChangePassword.cls" AutoCompile="1" Url="/csp/flagger" IsNamespaceDefault="1" InboundWebServicesEnabled="1" Recurse="1" AuthenticationMethods="64" DefaultTimeout="900" Directory="${CSPDIR}flagger" UseSessionCookie="2" CookiePath="/csp/flagger/" ServeFiles="1" ServeFilesTimeout="3600"/>
   </Namespace>
</Manifest>

调用代码的例子

<Manifest>
	<Role Name="${PMGNAMESPACE}" Description="Works User Role for ${PMGNAMESPACE} Namespace" Resources='"_tInstaller.Evaluate("${PMGDbResource}:RW,PMG:RWU")_"' RolesGranted="" />
	<!-- set locale -->
	<Namespace Name="%SYS" Create="no">
		<Log Text="Changing the Locale" Level="0" />
		<Invoke Class="Config.NLS.Locales" Method="Install" CheckStatus="true">
			<Arg Value="chew" />		
		</Invoke>
    </Namespace>
   <Namespace Name="flagger">
   	<Invoke Class="IRISConfig.Installer" Method="LoadTransactionalData" CheckStatus="true">
			<Arg name="pNamespace" Value="${Namespace}"/>
		</Invoke>
   </Namespace>
</Manifest>

创建User， Role

<Manifest>
	<User Username="ISC" PasswordVar="PASSWORD" Roles="%All" Fullname="ISC" Comment=""/>
   <Role Name="${PMGNAMESPACE}" Description="Works User Role for ${PMGNAMESPACE} Namespace" Resources='"_tInstaller.Evaluate("${PMGDbResource}:RW,PMG:RWU")_"' RolesGranted="" />
</Manifest>

Nampespace Mapping

<Manifest>
    <Namespace Name="FHIRNS">
		<Configuration>
			<Database Name="FHIRNS"/>
            <GlobalMapping Global="%SYS" From="IRISSYS"/> 
            <GlobalMapping Global="OAuth2.*" From="HSSYS"/> 
            <GlobalMapping Global="SchemaMap.*" From="HSLIB"/> 
            <ClassMapping Package="HS" From="HSLIB"/>
            <ClassMapping Package="HS.Local" From="HSCUSTOM"/>
            <ClassMapping Package="HSMOD" From="HSLIB"/>
            <ClassMapping Package="SchemaMap" From="HSLIB"/>
            <RoutineMapping Routines="HS.*" From="HSLIB"/>
            <RoutineMapping Routines="HSMOD.*" Type="INC" From="HSLIB"/>
            <RoutineMapping Routines="HSMOD.*" From="HSLIB"/>
            <RoutineMapping Routines="SchemaMap.*" From="HSLIB"/>
		</Configuration>
	</Namespace>
</Manifest>

其他还有很多的用法。想了解更多，可以看看文档说明里的Tag列表， 和template。

怎么执行cls文件

Using the Manifest

在Terminal里执行

%SYS>do ##class(MyPackage.MyInstaller).setup()

或者， 带上参数

%SYS>set vars("SourceDir")="c:\myinstaller"
%SYS>set vars("Updated")="Yes"
%SYS>do ##class(MyPackage.MyInstaller).setup(.vars,3)

During IRIS安装？

Export the manifest class as DefaultInstallerClass.xml to the same directory where the InterSystems IRIS install (either .msi, setup_irisdb.exe, or irisinstall) is run. It is imported into %SYS and compiled, and the setup() method is executed.

那么是irisinstall里面的什么语句在执行manifest呢？

# script, 用ISC_INSTALLER_MANIFEST, installer-manifest-example.xml

[root@silent jhvinstall]# cat cache_install.sh
#!/bin/bash
echo -n "Installing Cache..."
ISC_INSTALLER_MANIFEST=$3 ISC_PACKAGE_INSTANCENAME=$1 ISC_PACKAGE_INSTALLDIR=$2 ISC_PACKAGE_UNICODE="Y" ISC_PACKAGE_INITIAL_SECURITY="Minimal" ISC_PACKAGE_MGRUSER="cacheusr" ISC_PACKAGE_MGRGROUP="cacheusr" 
ISC_PACKAGE_USER_PASSWORD="sys" ./cinstall_silent

[root@silent jhvinstall]# ./cache_install.sh CACHE6 "/cache/tmpcache6" "/tmp/installer-manifest-example.xml"
Installing Cache...

写一个脚本执行

这里给一个脚本的例子，简短，但内容很丰富。

#!/bin/bash
# Usage install.sh [instanceName] [password]
instanceName=$1
password=$2
DIR=$(pwd)
ClassImportDir=$DIR/install
NameSpace="ENSDEMO"
CspPath="/csp/ensdemo"
SrcDir=$DIR/src/CLS
DirFront=$DIR/src/CSP/csp/demo

irissession $instanceName -U USER <<EOF 
SuperUser
$password
do \$system.OBJ.ImportDir("$ClassImportDir","*.cls","cubk",.errors,1)
write "installer导入成功"
Set pVars("DirBin")="$DIR/ENSDEMO"
Set pVars("DirFront")="$DirFront"
Set pVars("NAMESPACE")="$NameSpace"
Do ##class(App.Installer).setup(.pVars)
zn "%SYS"
set props("DeepSeeEnabled")=1
set sc=##class(Security.Applications).Modify("$CspPath", .props)
zn "$NameSpace"
do \$system.OBJ.ImportDir("$SrcDir","*.cls","cubk",.errors,1)
halt
EOF

第十五章 开发Productions - ObjectScript Productions - 开发Productions介绍

互操作性产品允许连接可能使用不同通信协议和不同消息格式的系统。可以使用 Java、.NET、ObjectScript、SQL 或业务流程、数据转换和业务规则的图形编辑器来开发产品。

文档

• 互操作性生产概述
• 在 ObjectScript 中开发
• 使用 PEX 在 Java 或 .NET 中开发
• 使用 SQL
• 业务流程 (BPL)
• 数据转换 (DTL)
• 业务规则
• 配置生产
• 使用推送通知定义工作流

在线内容

• ObjectScript：开发系统集成
• ObjectScript：构建自定义业务组件
• 创建数据转换

开发Productions介绍

本页介绍产品开发的过程。

环境考虑

只能在具有特定 Web 应用程序的支持互操作性的名称空间内使用 IRIS 互操作性。创建类时，应避免使用保留的包名称。以下小节提供了详细信息。

支持Production的命名空间

支持互操作性的名称空间是具有全局映射、例程映射和包映射的名称空间，这些映射使支持产品的类、数据和菜单对其可用。有关映射的一般信息，请参阅系统管理指南中的配置命名空间。

安装 IRIS 时创建的系统提供的名称空间不支持互操作性，但在社区版中，USER 名称空间是支持互操作性的名称空间。创建的任何新命名空间在默认情况下都启用了互操作性。如果在创建命名空间时清除了为互操作性Production启用命名空间复选框， IRIS 会创建禁用Production的命名空间。

重要提示：所有系统提供的命名空间在重新安装或升级时都会被覆盖。为此， 建议客户始终在创建的新命名空间中工作。

Web应用要求

此外，仅当命名空间具有名为 /csp/namespace 的关联 Web 应用程序时，才能在命名空间中使用产品，其中命名空间是命名空间名称。 （这是命名空间的默认 Web 应用程序名称。）

保留包名称

在任何支持互操作性的命名空间中，避免使用以下包名称：Demo、Ens、EnsLib、EnsPortal 或 CSPX。这些包在升级过程中被完全替换。如果在这些包中定义类，则需要在升级前导出这些类，然后在升级后导入它们。

此外， 建议避免使用任何以 Ens 开头（区分大小写）的包名称。这个建议有两个原因：

• 当编译名称以 Ens 开头的包中的类时，编译器会将生成的例程写入 ENSLIB 系统数据库。 （编译器这样做是因为名称以 Ens 开头的所有例程都映射到该数据库。）这意味着当升级实例并替换 ENSLIB 数据库时，升级会删除生成的例程，只留下类定义。此时，为了使用这些类，必须重新编译它们。

相反，当升级实例时，不需要重新编译名称不以 Ens 开头的包中的类。

• 如果在名称以 Ens 开头的包中定义类，则它们在所有启用互操作性的命名空间中都可用，这可能是合意的，也可能不是合意的。一个结果是，如果包名称以 Ens 开头，则不可能在不同的启用互操作性的命名空间中具有相同名称和不同内容的两个类。

查看Production定义

虽然在管理门户中创建和配置产品，但在选择的 IDE 中查看现有产品类的定义是有指导意义的。下面显示了一个简单的产生式示例：

请注意以下几点：

• production 是一个类，具体来说是 Ens.Production的子类。
• XData ProductionDefinition 块保存生产的配置信息。
• 每个<Item>都是一个业务宿主；这些也称为配置项。
• 每个业务主机指一个类。 ClassName 指定此主机所基于的类。这意味着当production创建这个业务宿主的实例时，它必须创建一个指定类的实例。
• 业务主机的名称是任意字符串。有时，为此目的使用类名会很方便，如本例所示。当创建大量使用相同类的业务主机时，此约定不起作用。

在开发过程的早期建立命名约定很重要。请参阅创建产品的最佳实践。缺乏命名约定会导致混淆。

• XData 块中的其他值都是设置。在顶部，<ActorPoolSize>; 是产品的设置。在业务主机定义中，PoolSize、Enabled、Foreground 和 InactivityTimeout 是这些业务主机的设置。

实现医疗系统之间的互操作性是一项艰巨的挑战。随着FHIR日渐普及，对FHIR标准的兼容如今已成为许多国家医疗信息系统的全国性强制性要求。FHIR标准最有价值的一方面就是所有内容可被机器读取，使得FHIR应用跨机构使用成为可能，帮助您距离“语义互操作性”更近一步。

不同系统在“对话”时候，如何让它们明白“带黑色条纹的白马”和“带白色条纹的黑马”是同一种动物（斑马）呢？FHIR是HL7国际（HL7 International）为满足当前医疗数据环境中的互操作性需求而创建的医疗数据标准，如今已成为许多国家医疗信息系统的全国性强制性要求。本视频介绍了FHIR的设计理念和关键构成，包括FHIR资源、FHIR Profile、FHIR扩展等。

第九章 Productions最佳实践 - Productions开发的最佳实践

Productions开发的最佳实践

本章是一个总体概述，旨在帮助团队成员为从事生产项目做好准备。它概述了开发任务并确定了有关 数据平台和企业集成的信息来源。本章中的信息适用于所有类型的生产项目。

项目目标

任何Productions开发项目的目标都是连接两个或多个系统。Productions是专门的软件和文档包，可为企业客户解决特定的集成问题。有关概述，请参阅互操作性产品简介。

本节从应用程序开发人员必须创建和配置以提供解决方案的软件元素的角度描述 IRIS。下一节“项目交付”总结了 IRIS 开发项目的顺序和结果。

项目交付

IRIS 产品架构支持向企业交付的各种风格：

• Productions可能包含企业的整个集成解决方案，或者产品可以适合企业已有的现有解决方案（或部分解决方案）。
• Productions可以根据需要替换、升级遗留系统或向遗留系统添加新功能，而无需删除或更改遗留系统的任何部分。
• IRIS 支持增量开发项目，因此开发团队可以根据企业的需要选择快速或缓慢地推进新旧系统之间的界限。

许多 IRIS 开发项目遵循与此类似的阶段顺序：

文档

阅读 IRIS 文档是一项基本的最佳实践。最好的起点是以下书籍和章节。每个都提供了进一步的交叉引用：

• Introducing Interoperability Productions 介绍了术语和基本概念。
• Developing Productions 描述了开发任务。
• 配置作品描述了如何执行与创建作品相关的配置任务。
• 本书后面的章节适用于部署接口路由解决方案。请参阅“路由制作的设计模型”和“将界面转换为制作元素”。

了解支持制作的 IRIS 平台功能也很重要。服务器端编程入门指南是一个有用的起点。

有用的背景材料包括：

• 使用 ObjectScript
• 定义和使用类
• 使用 SQL 网关
• 创建 Web 服务和 Web 客户端

其他有用的开发指南包括：

• 使用 SQL
• 使用 IRIS 多维存储（全局）
• 高可用性指南

语言参考资料包括：

• 对象脚本参考 有关系统实用程序和安全性的信息，请参阅以下文档：

• 系统管理指南

• 关于 Security

第八章 准备创建Productions - 规划 IRIS 服务器部署

容量和性能清单

IRIS 服务器的性能通过其处理峰值消息负载的能力来衡量。 IRIS 服务器的性能取决于许多组件和设置之间的复杂交互。 IRIS 服务器的负载主要取决于：

• 消息的数量和大小——峰值负载和每日负载都很重要。
• 每条消息都需要处理——在大多数情况下，希望简化消息的处理。例如，虽然验证消息有很多优势，但完整的验证可能会增加处理每条消息的大量处理负载。

在许多情况下， IRIS 系统上的消息负载会随着时间的推移而增加。这种增加可能是由于在生产中支持更多的业务功能或业务量的增加。服务器处理此负载的能力取决于许多组件和配置设置之间的复杂交互，包括 CPU 内核数量、多处理器架构、存储大小和速度、网络带宽和配置、操作系统缓冲区分配以及 IRIS 配置。没有简单的公式可以预测 IRIS 服务器的性能，因为它是一个复杂的交互，但可以估计、计划、原型和跟踪性能以确保 IRIS 服务器满足业务需求。

为确保 IRIS 服务器具有足够的容量并能够有效地处理其负载，应该

1. 估计负载—— IRIS 系统将处理的消息数量是多少？服务器启动后负载会逐渐增加吗？消息需要保存多长时间才能存档并从服务器存储中删除？
2. 规划能力——规划技能取决于实施类似 IRIS 服务器的经验。如果组织没有这种经验，应该与有这种经验的人一起工作：顾问或 销售工程师。可以联系 全球响应中心 (WRC) 进行推荐。
3. 原型服务器和负载测试——一旦估计了负载并计划了所需的容量，运行原型系统并监控其性能就很重要了。原型应确认您的容量计划并为提供比较已部署系统性能的基线。
4. 为代码和数据库规划磁盘布局——默认情况下，在启用互操作性的命名空间中创建的所有代码和数据都存储在同一个数据库文件中。通过将数据映射到多个数据库文件，可以更好地控制数据的存储位置，这有助于提高高端系统的性能，并更容易升级到新版本。将日志文件存储在与数据库文件不同的磁盘上也很重要，以确保磁盘故障不会导致数据丢失。
5. 部署服务器——安装和配置您的实时系统，包括任何冗余故障转移机器。
6. 跟踪负载和性能——在出现任何需要解决的性能问题之前，跟踪服务器性能以建立基线非常重要。应该收集总体和峰值消息负载、CPU 利用率、磁盘可用空间以及处理消息的平均耗用时间等指标。
7. 在性能问题变得严重之前解决它们——通过跟踪性能和预测增长，应该能够在性能问题成为组织性能的主要障碍之前计划升级和效率改进。

稳健性清单

稳健性是指 IRIS 服务器保持可用并能够从任何灾难中快速恢复的能力。稳健性取决于以下问题：

• 确保服务器具有高可用性。
• 备份数据，以便在发生故障时可以恢复数据并重新启动服务器。
• 冗余网络访问，因此服务器可以在出现网络故障时继续运行。
• 使用强大的网络服务器。不要使用与 IRIS 一起安装的有限 Apache 服务器。它是为了方便在开发系统上使用而提供的，并不是功能齐全的 Web 服务器。
• 灾难恢复程序和文档。

安全检查表

安全性是控制对数据的访问并保护服务器免受恶意攻击的能力。除了出于商业原因维护隐私外，通常还有隐私合规性要求。潜在的攻击可能旨在获取对机密信息的访问权限、恶意更新或删除信息，或者损害系统性能。安全性取决于以下问题：

• 用户帐户和密码策略——确保访问系统的用户经过身份验证。
• 仔细定义权限和角色——确保用户拥有正确的授权，并且他们拥有所需的访问权限，但没有更高的访问权限。
• 跟踪所有配置更改的审计跟踪——审计提供了一种机制来跟踪可能危及安全的系统更改。
• 满足隐私合规性可能需要的文档。
• 用户和操作员安全培训——如果用户对安全性不警惕，即使是最安全的系统也可能遭到破坏。
• 及时应用操作系统和应用程序安全补丁和升级。
• 控制对服务器的物理和网络访问——安全需要强大的防火墙、网络保护以及对服务器和网络硬件的有限物理访问。
• 数据库和日志加密——虽然数据中心周围的防火墙保护数据的安全性和完整性，但加密数据库和日志文件提供了额外的安全级别。

维修清单

除了确保在部署 IRIS 服务器后能够稳健、安全地处理其负载外，还需要确保它随着时间的推移继续保持良好的性能。需要程序来处理软件和硬件的更新以及如何响应意外需求。维护取决于以下问题：

• 常规消息清除和备份——在处理消息后保留消息以供查看和清除消息以释放新消息的存储空间之间存在折衷。

• 备份和恢复——执行定期备份和偶尔测试从备份过程中恢复。

• 硬件、软件和应用程序更新——计划在不影响系统性能或安全性的情况下允许这些更新。需要考虑的问题包括：

  • 安排硬件维护、软件补丁和升级，而不会在关键时刻丢失服务器访问权限。
  • 规划组件从开发系统到测试环境的部署，最后到实时运行的production环境。此暂存可以包括系统默认设置的使用、部署功能的导出、源代码控制系统或所有这三者。在应用到production服务器之前，在测试系统上测试安装过程和更新非常重要。
  • 源代码控制提供了一种机制来控制、监视和分级生产升级。这在多人更新相关组件的情况下尤其重要，但也经常用作从开发到生产的推广和版本控制的一部分。

• 及早发现任何问题的主动监控程序——应该已经定义了如何响应通过监控发现的任何潜在问题的程序。监控可以包括：

  • 生产监控——操作人员应该熟悉各种监控屏幕
  • 企业监控——如果有多个命名空间或系统，可以使用企业监控器来提供整个系统执行情况的概览。 Enterprise Message Bank 和 Enterprise Message Viewer 提供了一种监视来自多个产品的消息的方法。
  • 警报—— IRIS 警报可用于快速向正确的人员发出故障警报，而无需操作员监视屏幕。但是，生成太多警报可能会适得其反，必须找到正确的平衡点。警报管理提供了一种机制来跟踪警报的解决。

其他资源

尽管规划和部署 IRIS 服务器是一个具有挑战性的过程，但它比尝试修复处于故障状态的关键 IRIS 部署要容易得多。文档和类库文档提供了有关功能和安装的详细信息。以下是关键文件

• 监控产品
• 管理产品
• 安装指南
• 监控指南
• 关于 Security，它介绍了身份验证、授权、审计、托管密钥加密、TLS 和 安全的其他方面
• 数据完整性指南
• 高可用性指南

第七章 准备创建Productions - 使用 Productions 的路线图

以下部分概述了可能希望从中着手的文档资源，具体取决于角色。

IRIS 生产开发人员

如果是准备使用 IRIS 产品的开发人员，请参阅以下资源：

1. Introducing Interoperability Productions 概述了 IRIS 互操作性和可能希望包含在productions中的选项，并提供了指向更详细信息的指针。

2. 创建作品的最佳实践描述了设计、开发和维护作品的最佳实践。

3. Developing Productions，反过来，它会向指出应用程序开发集中的特定主题：创建Productions和其他指南。

4. 配置Productions描述了在作品中配置项目的详细信息。

IRIS 管理员

如果是准备使用产品的管理员，请参阅以下资源：

1. Introducing Interoperability Productions 概述了产品功能。
2. Managing Productions 解释了如何使用基于浏览器的管理门户来管理生产环境，并指出了使用管理门户执行的特定功能的详细描述。
3. 配置制作解释了如何构建和配置制作和制作组件以及更新现有制作的配置。
4. Monitoring Productions 解释了如何监控生产环境和各种生产组件。

规划 IRIS 服务器部署

本章描述了在部署production 服务器时必须考虑的主要问题。尽管本文档的前面章节涵盖了一些安装和部署主题，但它们旨在用于安装 IRIS 的开发版本。虽然这些主题涵盖了安装和部署的机制，但并未涵盖许多对于以稳健和安全的方式在生产服务器上部署 IRIS 至关重要的问题。

如果负责规划 IRIS 服务器部署，本章可以作为规划项目的清单，尽管您还需要考虑其他项目。

此检查清单确定了部署可靠、高效且可维护的 IRIS 系统必须解决的一些关键问题，但并未尝试提供有关这些问题的详细指导。本文档将问题组织成以下清单：

• 容量计划和清单——确保 IRIS 服务器能够有效处理峰值负载。
• 稳健性核对清单——确保 IRIS 服务器具有高可用性配置，并且可以从灾难中恢复。
• 安全清单——确保数据隐私和抵御攻击。
• 维护清单——确保 IRIS 服务器在软件和硬件更新的情况下长期持续正常运行。

Caché, IRIS在系统产生了最严重的问题时会产生错误信息并通知客户，但这并不足够。一是客户需要更多更灵活的通知消息，二是客户通常会有第3方的监控系统，因此得到Cache, IRIS的监控指标是必须的。

在所有的指标中，用户最关心的是以下几类：

• 硬件资源的使用，CPU, 内存， IO性能
• 数据库使用的硬盘的占用
• Cache, IRIS Journal的硬盘占有
• Mirror的状态
• License的使用情况
• Caché的性能指标

除此之外，第3方监控系统还需要获得Caché的一些系统信息，比如版本，instance名字等等。

指标的获得

有以下几个获得指标的方法

1. 系统仪表板及其Web服务

Caché的系统仪表板显示的数据包括：系统性能；系统运行状态 (运行时间，上一次备份，数据库，Journal状况等; 事务和进程情况；软件许可使用情况；任务，ECP等，还有就是错误和警告的数量。

系统仪表板包含4个子面板：Global和Routine统计数据；ECP统计数据；磁盘和缓冲器统计数据；系统资源统计数据。(IRIS和Caché稍有不同，缺少了“磁盘和缓冲器统计数据”) 。它们分别对应主仪表板中的相应模块，给出了更详细的数据。

第六章 介绍Productions - 其他Production 选项

本章概述了与制作相关的其他选项。

用户门户

与 Studio 和管理门户等后端工具不同，用户门户（正式名称为 用户门户）旨在供最终用户直接使用。下面显示了一个例子：

用户门户旨在使最终用户能够执行以下任务：

• 视图和仪表板，其中可以包括生产业务指标，将在本章后面介绍。
• 查看和管理工作流任务，将在下一节介绍。
• 向用户门户的其他用户发送消息，如上图左上角所示。

工作流

IRIS 为制作中的工作流程提供支持。工作流使得将人机交互合并到自动化业务流程中成为可能。企业内工作流的使用可能包括订单输入、订单履行、合同批准或服务台活动。

production 使用业务流程和业务操作集实现工作流。业务流程接收请求，组织完成该请求所需的任务，然后调用业务操作来执行这些任务。

这些业务操作中的每一个都将任务分配给一个工作流角色，该角色将任务放入属于该角色的每个用户的工作流收件箱中。要访问此收件箱，用户需要使用上一主题中介绍的用户门户。

当用户将任务标记为完成时，工作流引擎将继续执行下一个处理步骤。

业务活动监控

IRIS 包括将业务活动监控 (BAM) 作为企业集成项目的一部分所需的所有元素。

首先，它提供业务指标，这是专门的业务服务类，可以在可配置的时间间隔内计算特定值。这些计算可以采用多种形式，包括调用业务操作、联合数据库、 IRIS 数据库或包含在业务度量类中的任意源代码。请参阅开发产品中的“定义业务指标”。

其次，它提供了仪表板，即提供指标值实时图形显示的网页。每个仪表板显示一个或多个仪表，这些仪表显示业务指标。 IRIS 提供一套完整的内置仪表，包括速度计、灯条、交通信号灯等。

下面显示了一个显示业务指标的示例仪表板：

Alerts

如果发生警报事件，警报会在production运行时向适用的用户发送通知。目的是提醒系统管理员或服务技术人员存在问题。可以通过电子邮件、文本寻呼机或其他机制发送警报。

发布和订阅消息传递

Productions 还支持发布和订阅消息路由。该技术基于这些订阅者先前已注册以接收有关特定主题消息的通知这一事实，将消息路由到一个或多个订阅者。有关详细信息，请参阅管理制作。

Message Bank

Enterprise Message Bank 是一个可选的远程归档工具，可以在其中收集来自多个客户端产品的消息、事件日志项和搜索表条目。它由以下组件组成：

• Message Bank 服务器，这是一个简单的产品，仅由 Message Bank 服务组成，该服务接收来自任意数量的客户端产品的提交。
• 添加到生产中并使用消息库服务器地址配置的客户端操作（消息库操作）。

第五章 介绍Productions - 业务流程和业务逻辑

业务流程和业务逻辑

本章描述业务流程中支持的逻辑种类。

介绍

业务流程是production的中间部分。它们接受来自production内部主机类（业务服务或业务流程）的请求，然后处理请求或将它们转发到production内部的其他主机类进行处理。

建议在production中进行以下分工：使用业务服务从生产外部接收输入并将其（作为消息）简单地转发到production中。使用业务流程来处理任何需要的业务逻辑。使用业务操作从生产内部接收消息，并简单地为生产外部的目的地生成输出。也就是说，将业务逻辑集中在业务流程中。

因此，IRIS 为业务流程中的复杂逻辑提供了广泛的支持，并且该逻辑可以由非技术用户定义。

首先，业务流程可以包含自己的复杂逻辑。它还可以使用以下可重复使用的物品：

数据转换计算消息内容并将更改应用到消息内容。

业务规则在决策点更改业务流程的行为，或根据消息类型、消息内容或消息来源将消息发送到特定目的地。

IRIS 提供的工具使非技术用户能够定义业务流程、数据转换和业务规则。这些用户无需编程或绘图技能即可直观地查看和编辑逻辑。

请注意，业务流程、数据转换和业务规则中可用的较低级别选项之间存在重叠。有关比较，请参阅 Developing Productions 中的“业务逻辑工具的比较”。在决定如何组织逻辑之前，有必要查看这些选项。

业务流程的类型

IRIS 提供以下一般类型的业务流程：

• BPL 流程，基于类 Ens.BusinessProcessBP。要创建这些流程，可以使用专供非技术用户使用的图形编辑器。此编辑器在管理门户和 Studio 中可用。请参阅开发 BPL 流程。

这些流程的名称来自 BPL（业务流程语言），这是 IRIS 用于表示其定义的基于 XML 的语言。

• 路由进程，基于类 EnsLib.MsgRouter.RoutingEngine或 EnsLib.MsgRouter.VDocRoutingEngine。

IRIS 提供一组类来路由特定类型的消息。以下书籍指出了用于不同类型消息的路由过程：

要使用这些类，通常不需要编码。然而，有必要提供一组业务规则，本章稍后将介绍。

• 自定义业务流程，基于类 Ens.BusinessProcess 。请注意，前面列出的所有业务流程类都继承自此类。在这种情况下，需要使用支持的 IDE（例如 Studio）来开发自定义代码。

EnsLib 和 Demo 包提供了许多示例。

有关定义自定义业务流程的信息，请参阅开发产品中的“开发业务流程”。

产品可以包括这些业务流程的任意组合。

下面显示了 BPL 业务流程的部分示例，如 BPL 编辑器中所示：

数据转换

数据转换创建一条新消息，它是另一条消息的转换。可以从业务流程、另一个数据转换或业务规则调用数据转换。

当转换一条消息时，数据转换会换掉旧的消息主体对象（源）并将其交换为新的对象（目标）。在此过程中发生的一些转变可能包括：

• 将源属性的值复制到目标属性。
• 使用源上的属性值执行计算。
• 将计算结果复制到目标上的属性。
• 将文字值分配给目标上的属性。
• 忽略源上与目标无关的任何属性。

数据转换是基于 Ens.DataTransform或其子类 Ens.DataTransformDTL的类。

• 如果使用 Ens.DataTransformDTL，则转换称为 DTL 转换。要创建这些转换，可以使用专供非技术用户使用的图形编辑器。此编辑器在管理门户和 Studio 中可用。有关详细信息，请参阅开发 DTL 转换。

这些转换的名称来自 DTL（数据转换语言），这是 IRIS 用来表示其定义的基于 XML 的语言。

• 如果 Ens.DataTransform，则转换是自定义转换。在这种情况下，必须使用受支持的 IDE，例如 Studio。有关定义这些的信息，请参阅开发产品。

下面显示了一个示例 DTL 转换，如在 DTL 编辑器中所见：

业务规则

业务规则（也称为业务规则集）可以返回值、转换数据或两者。可以从业务流程或其他业务规则中调用业务规则。

业务规则是基于 Ens.Rule.Definition 的类。在管理门户中定义这些内容，该门户为非技术用户提供了一个可视化编辑器。下面显示了一个部分示例，如本编辑器中所示：

第二章 介绍Productions - 互操作性制作简介

互操作性产品的目的是使能够连接系统，以便可以在它们之间转换和路由消息。要连接系统，需要开发、配置、部署和管理集成多个软件系统的产品。本章介绍产生式和一些基本术语。

介绍Productions

互操作性产品是用于轻松连接系统和开发互操作性应用程序的集成框架。产品提供到各种消息格式和通信协议的内置连接。可以轻松添加其他格式和协议，并通过编码或使用图形界面定义业务逻辑和消息转换。Products提供了消息的持久存储，允许跟踪消息的路径并审核消息是否成功传递。一部作品中的元素被称为business hosts。business hosts.有三种，用途不同，具体如下：

• 业务服务Business services与外部系统连接并接收来自它们的消息。业务服务将消息中继到生产中的其他业务主机。
• 业务流程Businessprocesses允许定义业务逻辑，包括路由和消息转换。业务流程从生产中的其他业务主机接收消息，然后处理请求或将请求转发给其他业务主机。
• 业务操作Businessoperations与外部系统连接，并将消息发送给外部系统。业务操作从生产中的其他业务主机接收消息，并通常将它们发送到外部系统。

下图提供了生产和业务主机的概念性概述。

业务主机通过消息相互通信。所有消息都存储在 IRIS 数据库中，可以通过管理门户查看。

在大多数情况下（但不是全部），业务服务都有一个关联的入站适配器。入站适配器的作用是接受来自生产外部实体的输入。同样，业务操作通常有一个关联的出站适配器。出站适配器的作用是将输出发送到生产外部的实体。 IRIS 提供大量适配器来处理不同的技术。例如，对文件使用的适配器不同于对 FTP 的适配器。也可以定义自己的适配器。

下图显示了一个实际的生产，如管理门户中所见：

该视图显示了与一个业务主机 Demo.Loan.FindRateDecisionProcessBPL 之间的所有连接。请注意，此视图不显示适配器，因为它们已合并到业务服务和业务操作定义中。

设置

production 通常包括大量设置。设置是控制production 行为的可配置值。设置可以通过多种方式影响制作。例如，设置可以指定：

• 业务服务应侦听的 TCP 端口。
• 检查新输入的频率。
• 要使用的外部数据源名称 (DSN)。
• 连接到外部实体时使用的 TLS 配置。
• 保持连接多长时间。
• 其他等等。

IRIS 的一个重要特性是系统管理员可以在生产运行时修改设置。更改会立即生效。下面显示了系统管理员用来进行此类更改的网页示例：

生产及其业务主机具有 IRIS 提供的设置；它们对应于生产和业务主机类的属性。可以通过定义自己的 IRIS 类的子类，以完全相同的方式定义其他设置。还可以删除设置，以便对相应的属性进行硬编码且不可配置。

Production的消息流

互操作性Production通常按如下方式处理传入事件：

1. 入站适配器接收传入事件，将其转换为消息对象，并将其传递给关联的业务服务。
2. 业务服务创建后续请求消息，并将此新消息传递给生产中的业务流程或业务操作。
3. 接收请求消息的业务流程按顺序或并行执行一组预定义的活动。这些活动可能包括向其他业务主机发送后续消息。业务流程还负责生产中的大部分或全部业务逻辑。下一章将提供更多详细信息。
4. 业务操作封装了 IRIS 外部资源的功能，通常是外部软件应用程序。业务操作将请求消息对象的属性转换为外部应用程序 API 可用的格式。
5. 出站适配器管理与生产中的特定外部系统或应用程序通信的细节。它将 API 调用传输到外部实体。
6. 来自外部系统或应用程序的响应可以触发一连串响应消息返回到启动事件流的外部实体。细节取决于产品开发人员所做的设计选择。

作为演示，下图显示了一组相关消息的踪迹，production 发送这些消息以响应初始消息（在本例中由管理门户中的测试服务发送，而不是由外部源发送）：

处理还可以包括工作流，这使得人机交互合并到自动化业务流程中成为可能。企业内工作流的使用可能包括订单输入、订单履行、合同批准或服务台活动。 “其他生产选项”一章提供了更多信息。

第一章 IRIS 基础知识：使用互操作性制作连接系统

本文介绍了如何将系统与 IRIS 数据平台互操作性产品连接在一起。

为什么要连接系统？

连接系统涉及允许来自一个系统的消息由另一个系统处理。例如，以下场景需要连接系统：

• 为了提高效率，需要集成最初设计用于执行单一功能的系统。例如，可以通过集成跟踪库存、订购材料、记录销售和控制运输的各个系统来提高效率。
• 合并后，在独立组织中执行相同功能的系统需要协同工作，以使统一组织有效。

将系统连接在一起时，可能会面临以下挑战：

• 系统使用不同的通信协议：一个系统可能使用 TCP，另一个使用 SOAP，第三个使用 REST。
• 系统使用不同格式或基于不同标准的不同消息。
• 可能需要保证消息成功传递到正确的系统，并能够检测和纠正故障。
• 必须监视传输消息的系统，如果一次有太多消息，则提供消息队列，并监视整体系统性能以确保没有任何障碍。

虽然可以编写自定义应用程序来连接系统，但开发IRIS 产品会更容易、更快捷。 IRIS 提供了一个框架，允许连接系统并最大限度地减少或消除对自定义代码的需求。

介绍Productions

IRIS 产品是一个集成框架，用于轻松连接系统和开发应用程序以实现互操作性。产品提供与各种消息格式和通信协议的内置连接。可以轻松添加其他格式和协议，并通过编码或使用图形向导定义业务逻辑和消息转换。 Productions 提供了消息的持久化存储，可以追踪消息的路径，审计消息是否发送成功。生产由业务服务、流程和操作组成：

• 业务服务与外部系统连接并接收来自它们的消息。
• 业务流程允许定义业务逻辑，包括路由和消息转换。
• 业务运营与外部系统连接并向它们发送消息。

将系统连接在一起时，让它们理解其他系统的消息和文档可能具有挑战性。例如，考虑以下问题：

• 有两个独立的系统：一个是从多个联网设备收集数据，另一个是跟踪损坏设备和维修过程的工单系统。
• 当前的过程依赖于人为干预来监控设备并启动修复过程。这造成了延误并且不可靠。
• 任务是将两个系统连接在一起：监控正在收集的数据并自动启动修复过程。知道如何检测数据收集系统中的故障设备并知道如何启动修复，但即使数据代表相同的项目，这两个系统也会以不兼容的格式存储数据。
• 还需要记录从数据收集系统启动修复时的操作。

可以使用 IRIS 产品解决此问题。它提供了一个框架，用于定义一个接口，该接口接受来自数据收集系统的消息，将消息转换为修复系统可以理解的消息，然后将其发送到修复系统。它还存储消息路径的记录。

第五十四章 镜像中断程序

由于计划维护或计划外问题，镜像中一个或两个故障转移成员上的 IRIS 实例可能变得不可用。当故障转移成员的 IRIS 实例不可用时，其 ISCAgent 可能继续可用（如果主机系统仍在运行），也可能不可用（如主机系统关闭时）。本节提供了处理各种计划内和计划外中断场景的过程，这些场景涉及实例中断或一个或两个故障转移成员的全部中断。

如自动故障转移机制中所述，从主要故障转移成员到备份故障转移成员的安全和成功故障转移有两个要求：

• 确认主实例确实已关闭，并且没有被临时网络问题隔离。
• 确认备份具有来自主数据库的最新日志数据，因为它在主数据库发生故障时处于活动状态（请参阅镜像同步）或因为它已被手动捕获（请参阅主数据库的计划外中断而没有自动故障转移）。

在阅读和使用本材料时，可能需要参考自动故障转移规则来查看管理自动故障转移的规则。

有关使用镜像监视器确定备份故障转移成员是否处于活动状态或 DR 异步是否被赶上的信息，请参阅镜像成员日志传输和取消日志状态和监控镜像。

本章涵盖以下过程：

• 备份故障转移成员的维护
• 主要故障转移成员的维护
• 在故障转移成员维护期间避免不必要的故障转移
• 镜像中的系统间 iris 实例升级

计划外停电程序

• 备份故障转移成员的计划外中断
• 具有自动故障转移的主要故障转移成员的计划外中断
• 未发生自动故障转移时主要故障转移成员的计划外中断
• 主要故障转移成员的计划外隔离
• 两个故障转移成员的计划外中断

灾难恢复程序

• 在灾难期间手动故障转移到提升的 dr async
• 计划故障转移到提升的 dr async
• 使用提升的 dr async 临时替换故障转移成员

计划中断程序

要执行计划内维护，可能需要暂时关闭其中一个故障转移成员或托管它的整个系统上的 IRIS 实例。可能会执行此操作的情况包括：

• 备份故障转移成员的维护
• 主要故障转移成员的维护
• 在故障转移成员维护期间避免不必要的故障转移

注意：除了 iris 停止命令外，SYS.Mirror API 和 ^MIRROR 例程可用于手动触发故障转移。 有关在不触发自动故障转移的情况下关闭主数据库的信息，请参阅在维护故障转移成员期间避免不必要的故障转移。

当由于计划内或计划外的故障转移成员中断而没有可用的备份故障转移成员时，可以根据需要将 DR 异步成员提升为故障转移成员，从而保护免受数据库访问中断和发生主要故障时潜在的数据丢失的影响。有关临时将 DR 异步成员提升为故障转移成员的信息，请参阅使用提升的 DR 异步临时替换故障转移成员。

第五十三章 管理镜像 - Production自动启动如何在镜像环境中工作

当镜像系统启动时（此时还没有成员成为主故障转移成员）：

1. IRIS 不会启动任何访问镜像数据的生产，即使在 ^Ens.AutoStart 中指定了生产。如果成员成为主实例，则这些产品将在那时开始。
2. IRIS 确定实例上是否存在不访问镜像数据的命名空间。如前所述， 建议只在镜像成员上安装镜像产品。但是，如果安装了任何带有非镜像数据库的产品， IRIS 将启动 ^Ens.AutoStart 中指定的产品。 （此逻辑确保如果在镜像成员上安装了非镜像命名空间，它会在 IRIS 启动时启动。）

稍后，当该成员成为主要故障转移成员时， IRIS 会找到引用镜像数据的名称空间，以便它可以在这些名称空间中启动生产。如果遵循 的建议，则在实例成为主镜像成员之前，不应运行任何生产访问镜像数据。 IRIS 在开始生产之前首先检查生产是否已经在运行，特别是：

1. IRIS 通过计算在命名空间中作为 _Ensemble 用户运行的作业来确定生产是否已经在运行。如果有两个以上的此类作业，表明生产已经在运行， IRIS 会在消息日志中记录警告，并且不会尝试开始生产。
2. 如果正如预期的那样，生产没有运行， IRIS 会自动启动 ^Ens.AutoStart 中指定的生产。

医疗保健产品的镜像注意事项

将镜像与 IRIS for Health™ 和 HealthShare® Health Connect 结合使用时，有一些特殊注意事项。请注意，其他 HealthShare 产品有自己的镜像文档；以下注意事项不一定适用于这些产品。

如果正在镜像，则在设置 Foundation 命名空间时必须选择镜像数据库选项，如 IRIS for Health 安装指南或 HealthShare Health Connect 安装指南中的“使用安装程序向导”中所述。

在镜像 IRIS for Health 或 Health Connect 系统时，始终需要在备份成员的 HSSYS 命名空间中手动安排镜像任务。安排此任务可确保 Mirror Monitor Agent 正在运行。该代理在备份镜像实例上运行，以在主实例和备份实例之间同步存储在 IRISSYS（未镜像）中的项目。要安排镜像任务，请为备份成员打开终端并输入：

do ##class(HS.Util.Mirror.Task).Schedule("HSSYS")

在镜像数据库时，请记住以下几点：

• 不要镜像 HSLIB。
• 必须镜像 HSSYS。
• 可以镜像 HSCustom 以帮助保持自定义代码同步。

第五十二章 管理镜像 - 使用^DATABASE例程重新创建现有镜像数据库

使用^DATABASE例程重新创建现有镜像数据库

^DATABASE 例程的 10) Recreate a database 选项使可以在不更改数据库名称或大小的情况下清除现有数据库中的数据。 （有关例程的信息，请参阅 ^DATABASE。）可以将此选项用于镜像数据库，但必须在出现数据库的每个镜像成员上使用它，并且顺序与使用创建数据库选项的顺序相同创建一个新的镜像数据库——首先在主数据库上，然后是备份数据库，然后是数据库作为镜像一部分的任何异步数据库。

注意：如果使用 10) 重新创建数据库选项在主数据库上重新创建数据库，则必须对备份和镜像中的任何 DR 异步操作重复该操作；如果不这样做，数据库可能会在发生故障转移或灾难恢复时变得过时。强烈建议也对报告异步重复重新创建操作。

挂载/卸载镜像数据库

可以在任一故障转移成员上安装/卸载镜像数据库。但是，如果在备份故障转移成员上卸载，数据库将保持“陈旧”状态，直到重新安装，之后镜像会尝试自动赶上数据库。如果所需的日志文件在主要故障转移成员上可用，自动更新应该会成功，但如果主要成员上的任何所需日志文件已被清除，则必须从主要成员上的最近备份还原数据库。

将镜像数据库复制到非镜像系统

可以将镜像数据库复制到非镜像系统，并通过执行以下操作在该系统上以读写方式挂载它：

1. 使用将现有数据库添加到镜像中描述的过程在主要或备份故障转移成员上备份镜像数据库并在非镜像系统上恢复它（省略在外部备份恢复或冷备份后手动激活和赶上数据库的步骤恢复）。恢复后，数据库仍标记为镜像，因此是只读的。
2. 在非镜像系统上，使用 ^MIRROR 例程（请参阅使用 ^MIRROR 例程）通过选择删除一个或多个镜像数据库并按照说明从镜像中删除数据库。按照此过程，数据库以读写方式挂载。

镜像的生产注意事项

本节讨论适用于 IRIS 产品的其他注意事项，包括：

使用镜像数据创建支持互操作性的命名空间

因为创建支持互操作的命名空间需要在新命名空间中使用产品的数据库写入，所以必须在当前主镜像成员上创建具有来自一个或多个镜像数据库的映射的支持互操作的命名空间，而不能在备份上创建，其中镜像数据库是只读的。

IRIS 如何处理具有镜像数据的互操作性命名空间

IRIS 检查启用互操作性的命名空间中的映射，并确定该命名空间是否包含来自镜像数据库的任何映射，结果如下：

• 当启动或升级包含启用互操作性的命名空间的镜像成员时，生产仅在主要成员上启动。
• 升级 IRIS 时，某些任务需要对数据库进行写访问；这些任务仅在主镜像成员上执行。
• 如果发生故障转移并且某个成员成为主镜像成员，则在开始生产之前执行升级时跳过的任何任务（因为它当时不是主镜像）。

推荐用于 IRIS Productions 的镜像配置

镜像旨在成为一种高可用性解决方案，因此任何一个镜像实例上的无关活动都应该最少。也就是说，应该镜像任何镜像实例上的所有数据库。

客户有时会选择在任一节点上运行“不太重要”的产品，而无需镜像该数据。然而，这样的配置会产生可能难以维护的操作复杂性。因此 强烈建议避免此类配置，而是镜像所有数据库。

第五十一章 管理镜像 - 镜像的数据库注意事项

镜像的数据库注意事项

本节提供配置和管理镜像数据库时要考虑的信息：

IRIS 实例兼容性

镜像中的 IRIS 实例必须以多种方式兼容，如下所示：

1. 镜像中的所有 IRIS 实例必须：

• 使用相同的字符宽度（8 位或 Unicode；请参阅安装指南“准备安装”一章中的字符宽度设置）。
• 使用相同的语言环境（请参阅系统管理指南的“配置 IRIS”一章中的使用管理门户的 NLS 设置页面）。

注意：这些要求的一个例外是使用基于 ISO 8859 Latin-1 字符集的区域设置的 8 位实例与使用相应宽字符区域设置的 Unicode 实例兼容。例如，使用 enu8 语言环境的 8 位主实例与使用 enuw 语言环境的 Unicode 备份实例兼容。但是，使用 heb8 语言环境的 8 位主实例与使用 hebw 语言环境的 Unicode 备份实例不兼容，因为这些语言环境不基于 ISO 8859 Latin-1。

2. 故障转移成员必须启用相同的数据库块大小。此外，在故障转移成员上启用的大小必须在异步成员上启用。如果没有在另一个成员上启用添加到主数据库的镜像数据库的块大小，则无法将数据库添加到该成员的镜像中，
3. 故障转移成员和任何 DR 异步成员必须是相同的 IRIS 版本；它们只能在安装指南的“升级 IRIS”一章中使用镜像进行最小停机时间升级中描述的其中一个升级过程的持续时间内有所不同。一旦升级的成员成为主要成员，在升级完成之前，您不能使用其他故障转移成员和任何 DR 异步成员（特别是不能让它们成为主要成员）。

镜像不需要报告异步成员与故障转移成员具有相同的 IRIS 版本，尽管应用程序功能可能需要它。

成员字节顺序注意事项

• 分布式缓存集群中镜像数据服务器的成员不支持混合字节序（例如作为ECP数据服务器的镜像集）。当故障转移成员临时混合时——例如，当将服务器从一种字节序迁移到另一种字节序时——ECP 会话在故障转移后不会恢复。
• 创建镜像数据库或将现有数据库添加到镜像时，如果备份故障转移成员或异步成员的字节顺序与主要故障转移成员不同，则无法使用将现有数据库添加到镜像中描述的备份和还原过程；必须改为使用该部分中涉及复制数据库的 IRIS.DAT 文件的过程。此外，在使用该过程时，在将 IRIS.DAT 文件复制到所有非主要成员之后以及在这些成员上安装数据库之前插入以下步骤：
  • 在备份故障转移成员和每个异步成员上，转换复制的 IRIS.DAT 文件，如使用 cvendian 在大端和小端系统之间转换中所述。

使用 ^DATABASE 例程创建镜像数据库

可以使用 ^DATABASE 例程在镜像成员上创建镜像数据库。 （请参阅 ^DATABASE。）必须先在主要成员上创建新的镜像数据库，然后再在其他镜像成员上创建它。创建镜像数据库：

1. 运行 ^DATABASE 例程，并选择 1) 创建数据库选项。
2. 在Database目录下输入目录路径？prompt。
3. 在“是否更改默认数据库属性？”提示处输入yes。提示。
4. 在要更改的字段编号处输入3(镜像数据库名称：)。提示，然后在镜像数据库名称？处输入镜像数据库的镜像名称。提示。

注：如果要在其上创建镜像数据库的成员是多个镜像的成员，并且要创建的镜像数据库位于与默认情况下列出的镜像不同的镜像中，请在要更改的字段编号中输入(镜像集名称：)。提示，然后从列表中选择正确的镜像名称。如果在其上运行例程的成员只是一个镜像的成员，则此字段不能更改。

5. 根据需要修改数据库的其他字段，然后在完成更改后，在要更改的字段编号处按Enter键？提示，不指定任何选项。
6. 在配置：提示符下，在该数据库的数据集名称处输入数据库的数据集名称。这是在管理门户中显示的名称。
7. 在创建镜像数据库之前，输入对其余提示的响应。

当在备份成员和异步成员上创建镜像数据库时，它们会自动赶上在主要成员上创建的数据库。

注：不能使用^DATABASE例程将现有的非镜像数据库添加到镜像；有关所需过程，请参阅将数据库添加到镜像。

第五十章 管理镜像 - 在报告异步上使用 Dejournal 过滤器

在报告异步上使用 Dejournal 过滤器

仅在报告异步上，可以在给定镜像上设置用户定义的 dejournal 过滤器，让为每个日志记录执行自己的代码以确定哪些记录应用于该镜像中的读写数据库。定义过滤器后，可以在任意数量的镜像上设置它，并且可以随时设置、更改和删除过滤器。

重要提示：此功能仅适用于高度专业化的情况。应仔细考虑替代方案。为了控制将哪些全局变量复制到镜像成员，到非镜像数据库的全局映射提供了一种更简单、轻量级的解决方案。对于监控应用程序数据库的更新，在应用程序级别构建的解决方案通常更加灵活。

dejournal 过滤器允许报告异步跳过从主要接收的日志文件中的某些记录的 dejournaling。但是，这仅适用于读写数据库——最初以读写报告异步方式添加到镜像中的数据库，或者自数据库以只读方式添加到镜像后已清除 FailoverDB 标志的数据库。 （有关 FailoverDB 标志和镜像数据库在报告异步时的装载状态的详细说明，请参阅清除报告异步镜像成员上的 FailoverDB 标志。）如果在数据库上设置了 FailoverDB 标志，这意味着该数据库被装载为读取- 只是，dejournal 过滤器代码仍然执行，但所有记录总是在该数据库上 dejournaled，无论过滤器代码返回什么。

重要提示：设置 dejournal 过滤器会减慢它所设置的镜像的 dejournaling；这种影响可能很大，具体取决于过滤器的内容。

要创建 dejournal 过滤器，请扩展超类 SYS.MirrorDejournal 以创建镜像 dejournal 过滤器类。类名应以 Z 或 z 开头，以便在 IRIS 升级期间保留。

要在报告异步的镜像上设置 dejournal 过滤器，请导航到“编辑异步配置”页面（系统管理 > 配置 > 镜像设置 > 编辑异步），单击镜像此异步成员中所需镜像旁边的编辑 Dejournal 过滤器链接属于列表，输入镜像dejournal过滤类的名称，点击保存。要删除过滤器，请执行相同的操作，但在单击保存之前清除输入框。每当您在镜像上添加、更改或删除日志过滤器时，都会自动为该镜像重新启动 dejournaling，以便可以应用过滤器。但是，如果修改并重新编译镜像 dejournal 过滤器类，则必须使用 ^MIRROR 例程的镜像管理菜单上的管理异步成员上的镜像 dejournaling 选项手动停止并重新启动所有镜像上的 dejournaling。

一般镜像注意事项

本节提供镜像的考虑信息、建议和最佳实践指南。它包括以下小节：

Mirror APIs

类中的 SYS.Mirror提供了通过管理门户和 ^MIRROR 例程（请参阅使用 ^MIRROR 例程）以及许多查询以编程方式调用镜像操作的方法。例如，SYS.Mirror.CreateNewMirrorSet() 方法可用于创建镜像和配置第一个故障转移成员，而 SYS.Mirror.MemberStatusList() 查询返回列表镜像成员和每个成员的日志延迟状态。有关这些方法的说明，请参阅 SYS.Mirror 类文档。

如果使用外部脚本执行备份，可以使用 $SYSTEM.Mirror 类方法来验证系统是否是镜像的一部分，如果是，它的作用是什么：

$System.Mirror.IsMember()
$System.Mirror.IsPrimary()
$System.Mirror.IsBackup()
$System.Mirror.IsAsyncMember()
$System.Mirror.MirrorName()

其中 $SYSTEM.Mirror.IsMember() 如果该系统是故障转移成员则返回 1，如果这是异步镜像成员则返回 2，如果这不是镜像成员则返回 0； $SYSTEM.Mirror.IsPrimary() 如果该系统是主故障转移成员则返回 1，否则返回 0； $SYSTEM.Mirror.IsBackup() 如果此系统是备份故障转移成员则返回 1，否则返回 0； $SYSTEM.Mirror.IsAsyncMember() 如果此系统是异步成员则返回 1，否则返回 0； $SYSTEM.Mirror.MirrorName() 如果实例被配置为故障转移镜像成员则返回镜像的名称，否则返回 NULL。

还可以使用 $SYSTEM.Mirror.GetMemberType() 和 $SYSTEM.Mirror.GetMemberStatus() 获取有关当前 IRIS 实例的镜像成员资格（如果有）的信息，以及它在该角色中的地位；有关详细信息，请参阅镜像成员日志传输和取消日志状态。

主要故障转移成员的外部备份

使用 Backup.General.ExternalFreeze() 方法冻结对主要故障转移成员上的数据库的写入，以便可以执行外部备份，如数据完整性指南的“备份和还原”一章中所述，确保外部冻结暂停更新的时间不会超过 Backup.General.ExternalFreeze() 的指定 ExternalFreezeTimeOut 参数。如果发生这种情况，镜像可能会故障转移到备份故障转移成员，从而终止正在进行的备份操作。

在镜像成员上升级 IRIS

要查看在镜像成员上升级 IRIS 的选项和注意事项，请参阅安装指南“升级 IRIS”一章中的“最小停机时间升级镜像”。

第四十九章 管理镜像 - 停止备份和异步成员的镜像

停止备份和异步成员的镜像

可以暂时停止在备份或异步成员上进行镜像。例如，可能希望在短时间内停止备份成员上的镜像以进行维护或重新配置，或者在主数据库维护期间停止镜像，并且可能暂时停止报告异步成员上的镜像以减少网络使用。为此，请执行以下操作：

1. 导航到要停止镜像的成员的“系统操作”>“镜像监控”页面
2. 如果该成员是备份故障转移成员，请单击停止在此成员上镜像按钮。
3. 如果该成员是异步成员，请单击希望异步停止镜像的镜像所在行中的“在此成员上停止镜像”链接。 （停止一个镜像的镜像不会影响报告异步所属的其他镜像。）

该操作需要几秒钟。当刷新镜像监视器时，“在此成员上停止镜像”将替换为“在此成员上开始镜像”，可以使用它来恢复镜像。

重要提示：当停止对某个成员进行镜像时，镜像将保持停止状态，直到如前所述再次明确启动它。镜像的重新初始化或成员的重新启动都不会在成员上启动镜像。

注意：还可以使用镜像 SYS.Mirror.StopMirror() 和 SYS.Mirror.StartMirror()API 方法或 ^MIRROR 例程（请参阅使用 ^MIRROR 例程）来执行这些操作任务。

管理数据库取消日志记录

如镜像同步中所述，去日志化是通过将日志数据从主要故障转移成员应用到另一个镜像成员上的镜像数据库来同步镜像数据库的过程。尽管在常规镜像操作期间取消日志记录是一个自动过程，但在某些情况下，可能需要或想要使用 ^MIRROR 例程提供的选项来管理取消日志记录（请参阅使用 ^MIRROR 例程）。由于备份故障转移成员、DR 异步成员和报告异步成员之间的目的不同，因此在 dejournaling 和 dejournaling 管理方面也存在一些差异，特别是在 dejournaling 中断方面，无论是故意的还是由错误引起的。此外，用户定义的过滤器可以应用于报告异步所属的一个或多个镜像的去日志化。

注意：所有类型的镜像成员继续接收日志数据，即使暂停了一个或所有镜像数据库的取消日志化。 SYS.Mirror.AsyncDejournalStatus()SYS.Mirror.AsyncDejournalStart(), SYS.Mirror.AsyncDejournalStop(), SYS.Mirror.DejournalPauseDatabase()镜像 API 方法也可用于管理 dejournaling。

在备份或 DR 异步上管理取消日志

由于备份故障转移成员和 DR 异步成员上的镜像数据库应始终尽可能接近以分别支持作为主数据库的潜在接管或用于灾难恢复，因此只有受影响的镜像数据库才会因错误而暂停 dejournaling，而它继续为其他人。

例如，当备份或 DR 异步成员出现诸如 <FILEFULL> 之类的数据库写入错误时，发生写入错误的数据库的取消日志记录将自动暂停，但其他镜像数据库的取消日志记录将继续。卸载数据库并更正错误，然后重新安装数据库并通过从 ^MIRROR 例程的镜像管理菜单中选择激活或追赶镜像数据库选项或使用管理门户追赶数据库来恢复 dejournaling（请参阅激活和追赶）赶上镜像数据库）。

在 DR 异步上，还可以选择使用 ^MIRROR 例程的镜像管理菜单上的管理异步成员上的镜像取消日志选项暂停成员上所有镜像数据库的取消日志。 （此选项在备份成员上被禁用。）可以在 dejournaling 错误之后或出于维护目的使用它。例如，如果希望在取消日志记录错误导致取消日志记录仅针对一个数据库暂停时暂停镜像中所有数据库的取消日志记录，您可以执行以下操作：

1. 从 ^MIRROR 例程的镜像管理菜单中选择管理异步成员上的镜像取消日志选项，以暂停所有数据库的取消日志。
2. 卸载问题数据库，更正错误，然后重新安装数据库。
3. 从 ^MIRROR 例程的镜像管理菜单中选择管理异步成员上的镜像取消日志选项，以重新启动所有数据库的取消日志。 （此选项会自动激活出现错误的数据库并将其赶上与镜像中最新数据库相同的时间点。）

注意：当使用“管理异步成员上的镜像取消日记”选项暂停 DR 异步成员的取消日记时，取消日记不会重新启动，直到您再次使用该选项重新启动它。

在报告异步上管理取消日志

如异步镜像成员中所述，报告异步成员可以属于多个镜像。对于这些镜像中的每一个，可能希望数据库的 dejournaling 是连续的，或者可能希望 dejournaling 定期进行，具体取决于数据库的使用方式。例如，对于一个给定的镜像，可能希望在午夜和凌晨 4:00 之间取消日志，允许数据库在一天的剩余时间内保持静态以稳定报告生成。

此外，在卸载数据库进行维护或在取消日志记录期间遇到错误时，可能希望不同的镜像有不同的行为。对于一个镜像，暂停取消日志记录的数据库不落后于镜像中的其他数据库可能是最重要的，在这种情况下，您更愿意为整个镜像暂停取消日志记录；另一方面，镜像中的数据库尽可能保持最新可能是最重要的，在这种情况下，将只想暂停涉及的数据库。

当希望将报告异步上的一个或多个镜像作为一次性操作或定期暂停取消日志记录时，可以从 ^MIRROR 例程的镜像管理菜单中选择管理异步成员上的镜像取消日志记录选项以暂停为希望的任何镜像中的所有数据库取消日志记录。当想要重新启动 dejournaling 时，请再次使用 Manage mirror dejournaling on async member 选项。 （此选项在备份成员上不可用。）

与备份和 DR 异步成员不同，当报告异步成员上的数据库取消日志记录期间出现错误时，该镜像中所有数据库的取消日志记录将自动暂停。根据需求和政策，可以：

• 卸载遇到错误的数据库，从 ^MIRROR 例程的镜像管理菜单中选择管理异步成员上的镜像取消日志选项以重新启动镜像中所有其他数据库的取消日志，更正错误并安装数据库，然后恢复取消日志通过从 ^MIRROR 例程的镜像管理菜单中选择激活或同步镜像数据库选项或使用管理门户同步数据库（请参阅激活和同步镜像数据库）。
• 在更正错误并重新安装数据库时，允许整个镜像的 dejournaling 保持暂停状态，然后使用 Manage mirror dejournaling on async member 选项重新启动整个镜像的 dejournaling（此选项会自动激活有错误的数据库并捕获它到与镜像中最新数据库相同的时间点。）

当想要对报告异步成员的镜像数据库执行维护时，可以简单地卸载数据库，然后在维护后再次安装数据库并使用激活或同步镜像数据库选项或管理门户来同步数据库。 （如果维护涉及多个这样的数据库，请使用镜像监视器一次对所有数据库进行操作，如激活和赶上镜像数据库中所述。这比单独赶上数据库更高效，更省时。 )

注意：当报告异步成员上的镜像因错误而暂停取消日志记录时，该成员会在下次重建与主服务器的连接时尝试重新启动镜像的取消日志记录。当使用管理异步成员上的镜像取消日志选项暂停异步成员上镜像的取消日志时，镜像的取消日志不会重新启动，直到您再次使用该选项重新启动它。

WIN SQL是大多数用户使用的普通编辑器。但是我们不能使用winsql下载大量数据。所以我写了一个教程如何连接一个新的基于 Java 的编辑器，叫做 Squirrel SQL，它可以很容易地下载或导出 excel 或任何其他格式的数据。我还包括一个 Java JCBC 连接程序来连接 IRIS 数据库，尤其是镜像/故障转移服务器。

基于 SQL Java 的编辑器导出大量数据和用于 IRIS 连接的 Java JDBC 程序

基于 SQL Java 的编辑器导出大量数据

WinSql 是通常用于从 Iris 数据库中提取数据的编辑器，但是，如果没有许可的 winsql，则无法导出大量数据。

解决方案是使用基于 java 的编辑器，称为 Squirrel SQL。这是一个基于 java 的编辑器，您可以在从 IRIS 数据库执行 fetch 从编辑器中导出大量数据。这是用 Java 构建的开源 SQL 客户端，它使用 JDBC 连接到 IRIS 数据库。

Squirrel SQL 的特点

• Java 19 兼容性
• 多个插入符/光标编辑
• 全局首选项和新会话属性搜索
• Saved Sessions 的多项改进（用于保存和恢复 Session 的所有 SQL 编辑器的特性）
• 可配置的鼠标右键菜单
• 重新设计的添加/编辑 JDBC 驱动程序对话框

安装 Squirrel SQL 的步骤