Jack.Shang的技术博客

1. AppWorx管理简介

1.1. 总体说明

概述

AppWorx管理的主要职责：

1) 确保AppWorx 基本、代理、RMI服务器和WEB服务器启动和运行

2) 提供帐号给开发人员、分析人员、操作人员、网络管理员和数据库管理员

3) 设置基本选项

4) 定义主机和数据库登录

5) 定义输出设备

6) 管理AppWorx保留记录和报告输出

7) 在开发，测试和生产环境之间迁移AppWorx对象

1.2. 查看用户登录信息和发送广播

使用Connections窗口

注：要查看Connections窗口必须具有DBA角色

路径 View à View Connections

1) 查看用户登录报表

2) 广播一个消息，当前用户和以后登录的用户都可以接收到。

广播消息将持续有效，直到清除它，或停止并重新启动RMI的服务器。当你想清除的广播讯息， 简单地删除文本框内容，并点击 Broadcast按钮。

3) 查看连接AppWorx实例的RMI和代理列表，通过Agent字段可以识别类型：

² 如果为空，则为master

² RMI服务器显示为“RmiServer”

² 其他的都是代理的名字

解读服务器和主体连接信息

路径 View à View Connections à RMI Servers

1) RMI服务器信息

Master显示在表的顶端，会话ID是193662，它对应的RMI服务器具有同样的会话ID。Master的本地代理是PROD1。最后一个字段“Master”只对RMI服务器有效，如果显示为“OK”，显示RMI服务器支持Master。有下列两种情况，需要使用多个RMI服务器支持一个Master:

² 容灾 ，如果主RMI服务器不可用，AppWorx将自动切换到第二台RMI服务器

² 客户负载，如果有大量的客户连接到AppWorx，可能希望有第二台RMI服务器处理用户事务。

双击表中的条目，可以切换RMI服务器是否支持Master。

2) 代理信息

所列代理信息仅供参考。每行提供了一个代理的IP地址，端口号，会话ID，以及最后活动的日期戳。如果存在网络通信的问题，这些信息可能是有用的。那个 Master字段不适用于代理。

1.3. 增加现有的Master到RMI服务器

RMI服务器简介

RMI的服务器是一个向AppWorx Java Java客户端输出信息的进程。一个单一的RMI的服务器可以服务于一个Master，多个RMI的服务器也可以服务于一个Master，或RMI的服务器可以在两个或两个以上的Master共享。你可以通过 Masters.properties给RMI服务器增加Masters。此文件位于已安装RMI的服务器的data 目录。而通过RmiServer的 Config窗口，您可以给RMI的服务器分配master而无需停止RMI的服务器。

增加步骤

路径：View à RmiServer Config à new

字段	描述
Name	Master 名称
IP Address	IP地址
AWCOMM Port	AWCOMM端口，缺省为2136

此数据将写在Masters.properties文件中。

1.4. 翻译语言

翻译语言

路径：View à Translator Editor

可以使用翻译编辑器窗口把字段名称，工具提示和助记符翻译成另一种语言。如果想使用翻译语言，必须设置Options.properties 文件中UserLanguageFiles=true

1) General 允许编辑字段，这个页面包含两个搜索字段，可以搜索待翻译的键，也可以搜索它的值。

2) ToolTip允许编辑AppWorx按钮、图标、显示框的值。

3) Mnemonics可以改变助记的键值，它使用 Ctrl键的键盘导航。使用助记法时，不同的语言经常变化，不要使用通用的字符。不要在同一屏幕上使用重复的助记法 ，否则他们将不是所有的正常工作。

增加新语言文件

路径：View à Translator Editor à Locale 字段

翻译值存储在属性文件中。可以通过Locale字段选择属性文件

缺省的语言文件是Labels.properties，它的位置是：

$AW_HOME/web/classes/com/appworx/client/screen/util/

不能直接编辑Labels.properties文件，如果想增加一个语言文件，请复制Labels.properties并改一个唯一的名字。然后通过Locale字段选择。

要找到正确的扩展名的语言，请按一下Show All按钮。例如，德国的文件名称为Labels_de.properties 。一个国家的具体 版本的语言，创建一个有适当名称的空文件。例如，对于使用法语的加拿大，你将创建一个文件名为Lables_fr_CA.properties。然后只添加条目不同的Label_fr.properties文件。

1.5. 查看分配对象

查看分配对象

路径：View à View Assigned Objects

此窗口将显示对象的名字，它的描述，对象的类型，对角所分配的角色及其他信息。
这些信息主要目的是作为一个故障排除工具。注意：窗口底部的复制按钮。可以用它来复制信息到剪贴板并粘贴。

刷新分配对象

路径：View à Refresh Assigned Objects

如果觉得分配对象的数据过时，可以通过此功能刷新分配对象。

1.6. AppWorx目录结构

目录结构

如想了解AppWorx，重要的是知道AppWorx文件的结构和AppWorx 用于存放诊断文件的位置。以下是AppWorx常用目录位置。注它们位于AW_HOME目录中。

目录	内容
bin	AppWorx shell脚本，用于调用AppWorx进程。
c	编译，可执行的代码，用于每个AppWorx进程
cddir	安装文件
data	数据文件，保存AppWorx使用的信息
debug	标记文件，如果打开DEBUG
exec	预定义和客户化的AppWorx shell脚本
export	AppWorx Export工具产生的文件
import	AppWorx Export工具产生的文件，准备导入AppWorx
install	安装文件
log	日记文件，AppWorx操作过程中产生的.log .err和.debug文件
map	文件匹配目标系统中的对象和导入的对象地图文件有一个。扩展名为.dat
out	运行AppWorx作业产生的输出文件。包括 标准的日志文件和作业产生的输出文件。
pipe	管理文件，用于AppWorx后台进程
run	作业运行时AppWorx产生的pr和pm文件
rte	Java运行环境文件
site	用于AppWorx后台管理和客户环境变量
sql	各种SQL脚本，用于排错，安装，报表，测试和培训等
status	显示后台程序状态的文件
tmp	临时文件
web	Web访问和配置文件

UNIX主目录文件(Home)

也有一些重要文件在UNIX系统的AppWorx主目录。他们
说明见下表。

目录	内容
.netrc	通用UNIX配置文件，使用于FTP远程登录。这个配置文件可用于运行FTP模块。然而，使用.netrc文件能存在安全问题。您可以为每个FTP主机使用AppWorx登录取代. netrc文件。 AppWorx登录包含加密的用户名和密码 信息。
.profile	UNIX 脚本，设置用户环境、目录路径和其他设置
AWFILES.Z	AppWorx安装软件的压缩文件
release notes	显示当前Appworx版本新的内容和更新

2. 使用代理

2.1. 代理简介(Agents)

代理简介

一个代理是AppWorx的一个实例 。代理安装在每台作业执行的机器上。代理可以是Master的的本地代理，或远程代理。Master调度和控制作业的执行在所有分配给它的代理。代理组在处于两个或两个以上的机器的代理之间的分配负载。

使用AppWorx Masters和代理，您可以从任何 AppWorx客户端控制多台机器的作业 。AppWorx的Master驻留在一个服务器和通过本地的代理启动本地的作业。远程代理驻留在其他服务器，但从Master接受命令。对于Master/代理关系工作方式， AppWorx代理软件必须
安装在所有需要控制的机器。而AppWorx数据库必须驻留在一台机器中。

AppWorx如何运行作业

当Master认为作业应执行的，就把它提交给一个AppWorx队列中。代理轮询队列。当代理人发现一个作业应该运行后，它从队列中取出信息，并运行作业。当作业完成后，它发送状态息返回给Master。

如何部署Master/代理安装

一个master控制和监控作业在代理中的执行。这使得可以集中控制多台计算机。您可以有任意组合的Master和代理。例如，一个代理向Master报告，它可以包含其他Master。

在确定分配给master的master数量和代理数量，必须考虑机器和网络的可靠性。如果aster机器发生故障， Master的代理中的作业就不会启动。如果Master与一台代理失去网络通信，代理中的作业就不会启动。 然而，如果Master重新运行，或网络通讯得到恢复， AppWorx将在中断点恢复操作。

AppWorx Masters，代理和客户端采用SSL加密传输。

使用代理组

代理组在一台或多台机器的代理之间分配负荷。建立代理组和分配本地和远程代理。您可以当你定义一个模块时，可以指定代理或代理组。 当您给模块指定代理或代理组，是 告诉AppWorx程序的位置和运行的位置。 AppWorx将在代理组中第一个可用的代理中运行该程序。

2.2. 安装远程代理

远程代理简介

一般安装之后，AppWorx创建一个Master和它的本地代理。可以通过在AppWorx中增加代理对象用来增加远程代理，然后运行安装脚本。一个AppWorx远程代理通常用于在不包含Master的机器上运行作业。

在同一个实例中定义多个代理，只需要创建另外的代理对象，使用同样的IP地址和用户名。你只需要在第一次运行代理安装。

定义远程代理

路径：Agents à New

字段	描述
Name	名称最多可以有30个字符。如果在一台机器上安装两个或两个以上的远程代理，不要给他们相同的名称（即使他们服务于不同的Master实例） 。下面是保留字，不能用于Master或代理的名字;All，AWCOMM ， AGENTSERVICE ， AWAPI ，RMI， RMISERVER ，AGENT， 和MASTER。
Description	描述，限制30字符
IP address	IP地址，格式为：nnn.nnn.nnn.nnn，可以使用别名，但必须在Master和代理中都使用别名。
Sleep time	定义多少秒(10..1000)AppWorx将在处理循环之间等待。它也控制多少时间条件被计算。
CPU Limit	定义CPU使用率百分比，在AppWorx将产生不新的作业。当代理达到其CPU的限制，将进入一个CPU WAIT的代理状态。代理中的等待运行的作业也进行CPU WAIT的作业状态。新建的代理默认为80 ％ ，而升级版本AppWorx代理默认为99 ％。你可以看到实际 CPU使用率百分比代理人(ExploreràAgent SummaryàCpu字段)。每个代理及Maste 的CPU使用率大约每分钟更新一次。
Type	显示定义的代理的类型(如ORACLE，SAP等)
Thread schedule	设置并行作业最大数量，它们可以在同一时间运行在所有队列的代理上。编辑Master/本地代理的线程时间表在这一字段 将改变本地代理的设置。 注：可以通过Explorer窗口修改Masters和代理的线程时间表。
Environment Variables	指定一个或多个环境变量作为一个单一的AppWorx对象
OS type	显示操作系统是否使用UNIX,Windows,VMS或OS/400
Output directory	指定代理上运行的模块输出文件目录。当你选择一个操作系统类型时会自动填充一个缺省值。这个 字段最多32个字符。如果在这里输入一个新的目录，必须确认它的存在，并AppWorx对它有读/写权限 。可以使用AppWorx变量。 这个值可以变模块和用户指定的目录覆盖。注意：如果一个输出目录是指定的模块和 用户，用户的输出目录将取代模块设置。
User name	被选定的用户决定Awexe range分配给代理。 确保您的代理被分配到用户有充分Awexe range,，这是1000-9999 。用户分配到一个远程代理需要一个Awexe range的代理用于开始。
Active	如果不选中，代理的状态将是INACTIVE.，待定事务中所有的作业和刚提交的作业将进入History，并处于INACTIVE状态。
Agent debug	如果选中，AppWorx在代理的debug目录创建一个AgentService.debug文件
Use Job Count Load Balancing vs. CPU%	如选中，当代理在代理组中时，代理将考虑在待定事务中作业的数量与它最大的线程和实际CPU使用率负载平衡相比。建议保留此字段不选中。通过CPU使用率基础上的负载平衡，AppWorx 考虑到处理代理机器的所有应用的处理，包括AppWorx之外运行的东西。

安装步骤

1) 定义远程代理对象

2) 创建登录用户

3) 安装AppWorx远程代理软件

4) 开始网络侦听服务(for Windows)

5) 检验安装

其中，2-5步就参考AppWorx安装指南

2.3. 指定输出文件名

在awenv.ini文件中修改输出文件名

可以重命名系统的输出文件和报告的文件名，通过site子目录的awenv.ini文件。使用SYSTEM_OUTPUT_NAME设置命名标准输出文件（程序类型为o的文件来自AppWorx） 。使用REPORT_OUTPUT_NAME设定重命名由一个模块程序运行产生的报告文件（程序类型为b的文件来自AppWorx） 。这些条目可以包括替换变量，代入变量，环境变量。在[default]下设置，如下所示。

For UNIX:

[default]

SYSTEM_OUTPUT_NAME=$AW_HOME/training/out/{jobid}_{module}.txt REPORT_OUTPUT_NAME=b{jobid}_{module}.txt

For Windows:

[default] SYSTEM_OUTPUT_NAME=$AW_HOME/training/out/{jobid}_{module}.txt REPORT_OUTPUT_NAME=b{jobid}_{module}.txt

在输入新的设置之后，停止和重启AgentService进程后将生效。

2.4. 设置Master选项

设置Master选项简介

Master和本地代理AppWorx GUI中作为一个单一的对象。可以使用Master Options页面指定Master的几个选项。

设置时区

Time zone字段显示Master的时区。要改变Master的时区，你必须改变这个值，并从Master的awenv.ini文件中删除TZ设置， 并运行升级。

警告！如果你改变了Master的时区并选择’ No selection ‘ ，任何带时区设置的链 将失去他们的时区设置。

可能有一些作业，要运行在不同的时区的特定的时间。要做到这一点，可以为模块
或链选择指定的Time zone字段。你必须选择Master的时区，这样AppWorx会知道调整其启动时间多少个小时。
设置Master时区的步骤

1) 选择Master的本地代理

2) 通过Time zone字段选择时区

3) 删除awenv.ini文件中的TZ行。如TZ=EST

4) 运行soinstall，并选择3更新。输入正确的时区

5) 检查awenv.ini文件，出现新的设置。如TZ=PRC

指定Master的登录类型

登录中指定的Login type字段是用于模块默认选择 登录标签。有两种：

模块：作业利用模块的登录运行（除非模块定义要求使用用户的登录） 。

用户：作业利用用户的登录运行(除非用户登录定义为” No selection’,使用模块登录)。这个选项常用于用户有不同的数据库视图。

指定LDAP设置

如果Enable LDAP被选中，AppWorx将使用LDAP认证。

字段	描述
Java JNDI Factory class	Java JNDI 初始语境类
URL	LDAP 服务器的URL
Initial directory	LDAP 服务器的初始目录
Search by field	指定哪一个LDAP字段用于用户登录搜索(如：UID和CN)
Authentication mechanism	认证机制，值queryServer引起LDAP查询
SSL Enabled	允许SSL
Keystroke path	设置LDAP按键路径
Keystroke password	指定LDAP铵键密码

如想测试LDAP设置，请点击LDAP连接(Test LDAP Connection)按钮。

AppWorx LDAP解决方案仍在不断完善，想了解最新的LDAP实现信息，请参考AppWorx支持网站。

设置链的Master选项

路径: Master Options à Chains

字段	描述
Insert components into chain’s queue	设置链的组件运行在链选定的队列，而不是模块定义选定的队列。
Use virtual day for chain component days of week	指定链组件日期为虚拟工作日历
Defer schedules on startup	当Master停止时，推迟所有的调度的作业
Don’t Eval passed chain args when INITIALIZED	计算无格式的subvars （即subvars没有登录）分配提示给链中各组件时，而不是运行时处于INITIALIZED状态。保持这个选项未选中确保subvars在初始化时间得到计算，而不是准备时间。 Enclosing Subvar Prompt Values in { }:如果调度的链提示包含在{}中 ，链将传递subvar名称作为一个字符串给它的组件，而不是它的值，无论是否设置此选项。 Evaluating Subvars with Logins in Chain Prompts: 如果一个链 提示值是一个已登录分配给它的subvar，它将不再计算，直到作业执行或执行的条件被计算。

设置Debug的Master选项

路径: Master Options à Debug

字段	描述
Enable full condition debugging	设置全条件调试(方法)，在AppWorx客户端打开条件调试与在awenv.ini文件中设置CON|ALL一样，调试代码将写在Master的RmiServer.log文件中。
Enable TRUE condition debugging	只有当条件计算为真时，设置条件调试。
Master Debug	在当前RmiServer.log文件中打开调试
SQL Trace Debug	打开Oracle的SQL跟踪选项-结果保有存在Oracle用户日志的目录。一般不应该这样做，除非得到AppWorx产品支持。
Log Locks Encountered	在表appworx_errors插入一条记录，当A ppWorx试图更新记录，而同样的行在待定事务中被锁。

设置浏览器的Master选项

路径: Master Options à Explorer

字段	描述
Use module max revisions	当你定义一个模块，您可以指定Max # of revisions， AppWorx将保存的最多版本。选择此选项来设定。
Enable event log	创建一个事件日志用于惠普VantagePoint业务应用。
Disable initial predecessor inheritance	禁用前置链接继承。继承作业将有资格准备开始运行，除非其他作业还有前置链接。
Allow deleted status to satisfy SLR	成功自上次运行（SLR）的前置链接类型要求前置自从最后一次作业运行成功。选中此选项，一个删除的前任也满足了要求。
Allow aborted job to block single threaded queue	如果队列有一个线程时间表，它的Max Threads 为1，通过该队列，只能同时运行一个作业。当 队列包括最大线程为1的线程时间表，它被称为单线程队列。 如果选中此选项，一个带Stay in Queue on Abort选项的失败作业，留在队列上将占据队列的唯一线程。没有其他的作业允许通过队列运行，直到发生下列其中一种情况： •失败的作业被删除。 •失败的作业被重置和运行完成。 此选项仅适用于单线程队列。它不允许待定事务中 失败的作业占据一个线程队列中的线程 时间表有一个以上的最大线程。
Enable auditing of backlog changes	增加待定事务中的审计变化到aw_audit_table数据库表。审计数据通过运行AW_PURGE_AUDIT_HISTORY模块清除。
Automatically assign new role objects to themselves	当他们创建的时候，自动分配的新角色对象。
Schedules submitted as a group	当一个作业出现subvar问题时，阻止所有的预定作业。 当这个选项没有选中时，缺省的动作就是弹出例外，但运行所有其他预定的 作业。

设置密码的Master选项

路径: Master Options à Password

字段	描述
Do not require awrun passwords	允许使用不带-z <password> 参数的awrun工具
Disable user after 3 consecutive failed login attempts	当登录AppWorx客户端时，连继三次输入错误的密码时，失效用户
Force password change on new users	强制用户在第一次登录后修改密码
Force password to contain both alpha and numeric characters	强制用户密码包含字母和数字
Require password length of 6 characters	强制用户密码至少包含6个字符
Disable clearing of login passwords on re-login	当通过Re-login重进AppWorx时，在Login窗口记住用户密码

2.5. 启用AppWorx审计

AppWorx审计简介

AppWorx包括一个强大的审计功能。 AppWorx审计监督几个AppWorx对象及其部分的变化。使用AppWorx报告对象查看审计信息。一些AppWorx报告对象是AppWorx发行 ，它们被命名为 AW_AUDIT_ <对象或对象部分> 。例如， AW_AUDIT_CHAIN报告显示链的审计信息。这些报告反映了原始数据，变化，变化日期 和哪个AppWorx用户做了变化。

启用AppWorx审计

如果分配有管理员角色， 会看到一个Audit页面在Agents 编辑窗口。在这里，可以打开AppWorx审计。 AppWorx审计可以让你看到谁编辑了对象。当审计是开启，应该定期调度运行AW_PURGE_AUDIT_HISTORY模块。

Audit页面还显示，第一个对象什么时候更改的，以及已被更改的对象总数。为得到更详细的信息，点击Details按钮。

审计待定事务变化

如想审计待定事务变化，选择Master选项Enable auditing of backlog changes

清理审计表

AW_PURGE_AUDIT_HISTORY 模块用于清理审计表数据。 它包含一个提示，需要保留审计数据多长时间。它同时清理对象和待定事务审计信息，缺省值是60天。如你使用AppWorx 审计功能，你必须设置这个值并为这个模块创建一个调度。

2.6. 指定Master Email设置

设置Email

如想发送通知邮件，必须在master/代理中指定邮件发送人信息。 要指定Master的电子邮件设置，选择master/本地代理的Email页面，然后指定主机，开放 端口，发件人。确定电子邮件设置后，可以给发件人发送测试电子邮件，点击Test按钮。

2.7. 定义代理组

代理组简介

当给代理组提交模块， AppWorx在代理组中第一个可用机器组行它。如果Multi-Execution选项被选中，模块和链 将在分配的代理组的每一个代理中运行。没有Multi-Execution选项的代理组被称为正常代理组。

可以给模块分配代理组，只能给链分配Multi-Execution代理组。

创建代理组步骤

1) 从Agent Groups窗口，点击New

2) 选择Standard代理类型，点击OK

3) 输入代理组名称和描述

4) 如果你想在所有的代理中运行作业，点击Multi-Execution

当通过Multi-Execution代理 组运行模块，链，链的组件时， AppWorx自动创建作业的副本，然后在组中的每个代理中运行。每个作业都出现在待定事务中，这样可以跟踪执行。

5) 给代理组分配一个或多个代理

APPWORX_AGENTS代理组

APPWORX_AGENTS代理组由SODELETE模块使用，应当包含所有的APPWORX代理。

SODELETE删除达到保留日期的或达到最大版本数的输出文件。必须确保SODELETE在所有的AppWorx代理执行。SODELETE是SYSTEM链的一部分。

动态负载平衡算法

负载平衡提供动态的手段，用来平衡一些机器之间的处理负载。AppWorx提供了灵活性的方法来管理负荷分配，以满足几乎所有的站点。

决定代理顺序由下列条件决定：

1) 代理的优先级

2) 代理负载因子乘以CPU利用率的值。如果选中选项Use Job Count Load Balancing vs. CPU%，代理因子 乘以当前代理正在运行的作业的数量超过代理的最大线程数。

3) 代理最后活动的时间信息

分配优先级和负载因子

在给代理组增加代理之后，下一步就要给组中的每一个代理分配优先级和负载因子。路径：Agent Groups à Edit.

Priority: 优先级，代理的优先级，与代理组中的另他代理相比较。Priority字段数值越低，运行作业的优先级越高。

Load factor:负载因子，代理的处理能力，与代理组中的另他代理相比较。Factor字段数值越低，运行作业的处理能力越高。例如，如果机器A有Factor为20，而机器B有机器A的一半处理能力，则机器B的Factor为40。

2.8. 管理系统记录

系统记录简介

SYSTEM链是AppWorx每日管理的关键。它包含两个模块：DELDEFAULT和HISTORY_PURGE。

第一次新安装后，SYSTEM链的开始时间设为00:00。如处理较轻，你可能希望更改这个设置到一个不同的时间。

通常，依赖SYSTEM链处理历史记录和输出记录。然而，你可以单独提交每一个模块去代替链。

删除输出文件

当定义了一个模块，可以设置输出保留的天数。SODELETES模块(别名DELDEFAULT)删除达到保留天数的输出文件。

SODELETE模块也删除AppWorx进程创建的日记文件。缺省地，7天以后，它们被删除。你可以更改这个设置到另一个的天数。更改方法：

awenv.ini 文件 à [default]段 à LOG_RETENTION_DAYS

删除历史记录

HISTORY_PURGE模块删除所有的过期的历史记录，过期天数在模块的参数中指定。缺省是60天。如果你想使用不同的值，可以单独提交HISTORY_PURGE模块。

为了满足SLR的前置链接，数据库中必须有一个参考的前置作业。运行HISTORY_PURGE模块将删除这些参考。大多数情况下，这绝不会是一个严重的，因为历史在前置被检查之前保存多天 。如果这种情况发生，使用条件取代SLR前置。

3. AppWorx进程 (Processes)

3.1. AppWorx进程简介

进程简介

所有AppWorx代理现在都是多线程的Java代理。不再有C代理。awcomm, AgentService 和awapi进程运行在所有代理中。通常情况下， RmiServer进程运行在的主机上。为了确保Master与各种进程安全通信，所有信息都会加密。

要查看AppWorx进程状态，使用awstat命令。

awapi进程

awapi进程为非持久性进程awexe，awprint和awrun 处理事务。它作为awexe和awprint执行事务处理功能的集中器 。它对AgentService保持一个开放的接口以提高响应。

3.2. 启停进程

启停进程简介

使用startso和stopso命令启动和停止AppWorx进程。在启停进程之前，必须设置环境变量。环境变量文件是：$AW_HOME/site/sosite

不带参数的启停命令

不带参数的startso命令启动如下进程：

1) awcomm

2) AgentService(它启动awapi)

3) RmiServer

不带参数的stopso命令是停止AgentService进程

启动进程，但不待定作业

如果想开始AppWorx 进程，但不允许Master执行作业，直到有机会查看待定事务的内容。可以使用如下命令：

startso

stopso master

stopso master命令不会停止任何实际的进程，因为这些要素RmiServer进程上已经完成。它将使master进入停止状态。

启停Apache进程

使用命令apachectl start和apachectl stop来启停Apache 进程。

改写进程启动等待时间

如果进程在规定的时间内没有启动，启动进程将异常中止。可以在awenv.ini文件中改写进程启动等待时间。如果设为0，将使用缺省的时间。缺省的时间为：

Agentservice_wait=60

Awapi_wait=60

Rmiserver_wait=60

Awcomm_wait=10

立即停止进程

使用命令stopso –now <进程名> 来立即停止进程。

3.3. watchworx进程

watchworx进程简介

watchworx进程用于检查并重启AppWorx错误的进程。

AppWorx支持大多数的生产环境没有任何问题。然而，在某些情况下，如网络或数据库的问题频繁发生，或机器和应用是在不断变化， WatchWorx确保AppWorx进程启动和运行。 WatchWorx检查awcomm ， AgentService ， awapi ，并RmiServer进程。如果这些进程意外退出， WatchWorx将重新启动这一进程。如果一个进程被系统手动停止或业务人员使用stopso命令，Watchworx将不启动这个进程。

注意：重启一个远程代理的AgentService进程可能需要7至10分钟。这取决于watchworx进程的循环周期、网络连接和机器速度。

AppWorx进程每一次休眠周期向watchstatus.log文件写入信息。此文件位于log目录。

在UNIX系统，每次代理安装，WatchWorx作为一个独立进程运行。在Windows，系统中，WatchWorx作为一个服务运行在Master和远程代理机器上。

watchworx环境变量和项

有几个环境变量的影响WatchWorx 进程，它们被设置在awenv.ini文件的[WatchWorx]段。格式为：variable=<value>。

变量	描述	缺省值
initial_sleep	WatchWorx等待所有进程的开始的最初的时间	UNIX:120秒 Windows:20秒
watch_sleep	WatchWorx进程检查之间的休眠时间	30秒
mult_factor	当一个进程不在存在，WatchWorx比较最新状态更新时间期间和sleep_time * mult_factor 。默认情况下， WatchWorx 的mult_factor等于7 。如果进程睡眠时间等于60 秒， WatchWorx将不会在闲置代理采取行动除非有时间差 超过420秒。由于用户干预的正常关闭，WatchWorx不会重新启动进程。	7
max_cycles	max_cycles变量设置WatchWorx将尝试每隔x秒重新启动一进程的次数，每隔x秒钟由min_time_reboot 变量设置。在指定数目的重新启动之后，它会尝试重新启动进程每隔y秒数，y秒由max_time_reboot变量设置。	3
max_time_reboot	重启的最大的等待时间	1800秒
min_time_reboot	重启的最小的等待时间	300秒
watch_wait	Stopso命令与startso命令的休眠时间	3秒
watchstatus_file	WatchWorx进程状态日记文件，必须是全路径	缺省在log目录的watchstatus.log

进程状态

进程有2种状态：offline和online。

Offline状态显示进程被手动停止，WatchWorx将不会试图重启此类进程。

Online状态显示进程被自动启动，如果在指定的时间间隔内，更新时间戳失败，WatchWorx将试图停止和重启此类进程。

使用WatchWorx.notify发送进程重启通知

WatchWorx允许通过WatchWorx.notify脚本增加活动。每当WatchWorx试图重启AppWorx进程时，WatchWorx.notify脚本将运行。脚本必须放在AppWorx的exec目录。在UNIX中，这个脚本必须有执行权限。

WatchWorx可以传递给脚本三个参数：
•进程名称
•进程类型
•关于WatchWorx的行动一条消息

例：echo “`date`AppWorx process $1 of type $2. WatchWorx message: $3. “|mail [email@address]

WatchWorx进程工作方式

如果所有的进程有规律地写入WatchWorx状态表，WatchWorx休眠60秒，然后继续检查。WatchWorx采取行动的基础是：进程的类型及当前时间和状态表时间的差异。有两个组进程，WatchWorx处理RmiServer进程不同于其他的进程。

对于RmiServer进程

RmiServer状态	进程的PID	时间差异	WatchWorx动作
Online	Exists	<sleep_time*factor	休眠
>sleep_time*factor	关闭并重启进程
Does not exist	—	并闭并重启进程
Offline	—	—	休眠

对于其他进程

进程状态	时间差异	WatchWorx动作
Online	<sleep_time*factor	休眠
	>sleep_time*factor	等待一定的秒数mult_start*sleep(缺省为420秒)，然后关闭并重启进程
Offline	—	休眠

3.4. awcomm进程

awcomm进程简介

awcomm进程为一台机器的Masters和代理提供了一个直接服务端口，它保存分配给Master的端口，并提供给客户进程。客户端进程是一个沟通与AppWorx事务处理例程的进程。在一个典型的配置中，每台机器只有一个awcomm进程。

在正常情况下，awcomm不需要被停止，除非你计划删除其AppWorx实例。

启动例程

awcomm进程在第一次执行startso时第一个启动。它从data目录的net_conn.dat读取恢复信息。它处理来自awapi,AgentService和RmiServer进程的请求。在任何时候任何通信发生时该进程需要存在和操作。

侦听端口

缺省地，awcomm进程的侦听端口为2136，AWCOMM_PORT必须在RMI服务器/Master及所有的远程代理中保持一致。如果防火墙，必须开放这个端口的输入和输出通信。检查端口是否被使用，可以用如下语句：netstat -an|grep <port number>。

3.5. AgentService进程

AgentService进程简介

AppWorx内部通信进程是由AgentService进程管理。AgentService进程启动，在端口范围49152-65535查找第一个可用的端口，并登记其awcomm进程的Master信息，以便未来的客户端可直接连接。

配置AgentService

可以在awenv.ini文件中设置如下变量用于配置AgentService

变量	描述
AgentClientPort	远程代理的端口，用于接收Master的数据
AgentServerPort	在Master上的侦听端口，用于AgentService和awapi进程的通信。如果不指定，范围从49152到65535，进程启动时，AppWorx每次指定随机的端口。如果没有防火墙，一般不指定。
AWCOMM_PORT	Awcomm进程侦听端口
Master_IP_Address	Master的IP地址
M_A_SSL	指定在Master和代理之间是否使用SSL协议

3.6. RmiServer进程

RmiServer进程简介

AppWorx RMIServer用于给AppWorx Java客户端提供信息的进程。它从AgeentService进程得到Oracel数据库的连接信息和从master.set解密登录信息。如果RMI Server不活动，则AppWporx Java客户端不能启动

启动例程

使用 startso rmi启动 Rmi Server例程。它调用Java虚拟机。RMI Server启动并连接到Options.properties文件指定的RMIRegistryPortNumber端口.

连接到awcomm后，RmiServer进程尝试连接到AppWorx数据库。它将不停尝试，直到连接。如果成功的数据库信息是不正确，Rmi Server无法启动。所以RmiServer启动的前提是：

1) awcomm和Master的AgentService必须启动，以得到数据库SID连接信息

2) RMI Server目标数据库的Net8(SQL*Net)必须运行。

有两个配置文件与RMI Server有关：Options.properties和Masters.properties

Options.properties文件的参数与awenv.ini类似，它不使用段分开。如果一个值被设置了两次，则在文件中的最后一次有效。

变量	描述
RMIHostID	RMI Server所在机器的IP地址
RMIRegistryPortNumber	RMI Server使用的端口
RMIDataPortNumber	RMI Server传输数据端口
ServerCodebase	UserWorx.jar所在的URL路径
ServerLog	日志地(正常信息和debug信息)
Debug	Debug设置，缺省为false
SSL	设置是否使用SSL加密，缺省为on
ExitPage	离开客户端的网页
SQLOPER_HOME	AppWorx安装地点(AW_HOME)

Masters.properties为AppWorx Masster提供了端口和IP地址信息

变量	描述
AwCommPort	Awcomm端口
<master name>	用于增加Master

RMI Server故障

下列情况可能引起RMI Server出现故障：

1) Net8(SQL*Net)没有运行或数据库连接没有运行

2) Java没有安装或操作系统的补丁不正确。

3) 客户端和RMI Server之间丰存在防火墙问题

4) awenv.ini文件中不正确的变量设置，包括：MasterServerPort, MasterClientPort, DB_SID, DB_IP, DB_PORT。

3.7. awexe进程

awexe进程简介

awexe进程就是所谓的’瘦’客户端。它通过awapi （后端客户端）连接到AgentService进程。该awexe进程只能运行列在awserver_sql.dat和awserver_sqlusr.dat文件中的内容。文件位于AppWorx data目录。变量（ AW_HOME ，AGENT，PATH= $ AW_HOME /bin： $PATH）必须设置正确，一个AppWorx用户必须存在相匹配的操作系统的用户， 和用户必须有正确的Awexe Range。 Awexe用于安装，导入和导出，命令行程序，作业启动和完成，以及startso和stopso等。

启动/运行例程

awexe进程提交请求给awapi进程，awapi进程按序提交给AgentService。要看操作系统用户是否可以执行语句，AgentService进程验证操作系统（ OS ）的用户和awexe命令范围是否是分配给用户的命令范围。如果权限是正确的，语句被执行，结果传递给awapi，后者回传给awexe 。

awexe 范围

当你定义了一个AppWorx用户，你可以通过Awexe Range字段限制用户执行命令的范围。

• 1000-1999: Used for AppWorx background processes.

• 2000-2999: Utilities for the general user.

• 3000-4999: Reserved for consulting.

• 5000-9999: Used for custom definitions.

awexe故障

下列情况可能引起awexe出现故障：

1) awapi和AgentService进程没有运行

2) 变量设置不正确

3) 命令太长

4) 操作系统用户设置不正确

5) Appworx用户没有权限执行功能。(Awexe Range限制)

6) 操作系统用户在c,bin和exec目录没有读(执行)权限，在pipe目录没有读写权限

4. 作业如何运行

4.1. 作业运行简介

总述

当一个模块被请求或计划运行时，作业开始了。Master启动程序执行，并通知适当的代理。数以千计的个体模块（及相关程序）能够在同一的时间执行。

下图显示的参与处理作业的常规阶段。在递交阶段（向下箭头）设置初始状态，创建运行环境，并传递信息。返回阶段（向上箭头）处理作业输出记录，后期加工，和条件。

Master传递合格的作业到适当的代理。代理通过建立和执行脚本处理这项作业。脚本建立了作业的环境，执行任何运行脚本，并调用程序类型的脚本。

程序类型的脚本调用应用并完成和AppWorx，程序及运行的应用程序之间的联络 。与此同时，Master执行DURIN的条件。

程序执行后，输出（可选）登记。当输出登记时，建立输出文件和运行的作业的连接，并储存在 AppWorx数据库。登记后，在报告作业完成状态前运行扩展。Master执行AFTER条件和移动作业到历史。

阶段条

每个主题包含一个阶段条，它概述了模块的执行每个阶段关键组成部分。箭头指示了执行方向。这是重要的，因为该阶段是双向的，这意味阶段是程序执行之前，期间和之后。想想一个模块的执行看成一系列调用子脚本的脚本，传递参数和输出结果。

4.2. 向Master请求

启动作业的方式

1) 请求窗口

2) 调度的模块和链

3) API调用

Master处理过程

一个作业提交之前， AppWorx Master分析作业的适合运行的特征。特征包括：单独运行，优先级，线程链，冲突，开始时间，队列线程，代理组/负载平衡，代理线程，及代理的可用性。

如果作业适合运行，Master评估所BEFORE条件，并确定这项作业是否可能会运行。下面活动可能会推迟或阻止模块的运行。包括WAIT UNTIL MET, DELAY TASK, RESCHEDULE TASK, SKIP TASK,和 HOLD TASK。

如果条件不排除模块运行，Master找到代理和通知代理。Master更改作业的状态为STARTING。

Master创建两个文件：pm和pr。pm文件创建一个新的环境，调用BODY脚本。pr文件包含每个模块提供的参数。这些可能在程序类型接口脚本或程序中使用。

pr文件

pr文件包含来自模块提示的参数。pr文件的文件名（ pr. <seq_no> ）通过pm文件在系统环境变量par输出。完整路径名称的文件保存在变量so_par。par文件总是在AW_HOME的run子目录下，可（可选）用于程序或程序类型脚本。

pm和pr文件，在作业执行后，被BODY脚本删除，但与作业有关的所有信息是显示在作业相应的SYSOUT文件中。

设置和输出环境变量

有四种方法可以一个程序设置环境变量和输出它们(使它们有效) 。

1) AppWorx GUI

2) site目录的sosite文件

3) PREFIX运行扩展

4) 程序类型接口脚本

AppWorx在运行时大约定义40个环境变量，并写入到pm文件。如果你在sosite文件中定义了一个环境，如OUTPUT，在运行，它将自动被pm文件覆盖。你可以使用PREFIX脚本或程序类型脚本修改pm中定义的环境变量。

Master处理(从BODY返回后)

Master处理所有的AFTER或者DELETED条件，然后转移作业到历史或者重启它。

这样，整个模块的执行就结束了。

4.3. pm文件

pm文件简介

在Master有代理执行pm脚本前，它直接设置两个环境变量： db_login2和b_password2 。这些都是直接设置，使他们决不存在在操作系统的文件中。代理启动pm文件设置环境和输出环境设置到一个新的环境(设置子-shell的环境)。然后pm文件调用BODY脚本。
pm文件为模块设置环境变量和它的相关子对象(数据库登录，程序类型，输出规格说明)。

通过sosite文件增加或删除环境变量，可以更改AppWorx的环境设置。也可以增加PREFIX脚本去增加，修改或删除环境变量。也包括Oracle指定的变量比如ORACLE_SID,ORACLE_HOME和TWO_TASK。

在多个位置使用seq_no

AppWorx给每一个提交的模块分配一个唯一的作业标识号(job_id)和次序号(seq_no)。job_id用于生成作业输出文件的名字。输出文件被SYSTEM链有规律地删除。pr和pm文件在程序运行完成后被删除(除非启用DEBUG)。如下表所示：

文件名	作用/描述	目录
pm<seq_no>.sh	传递系统环境变量	exec
pr<seq_no>.sh	传递提示	exec
o<jobid> (UNIX) o<jobid>.log (Windows)	默认的系统输出文件：待定作业的输出接收	out
b.<jobid> (UNIX) o<jobid>.lis (Windows)	默认的程序输出文件：记录程序产生的结果	out

4.4. BODY

BODY简介

BODY脚本设置作为的状态为RUNNING，记录作业的进程ID(pid)，通知作业的代理，使其能监控作业的完成。登记系统输出，执行所有的PREFIX脚本，最后调用程序类型脚本。BODY立即创建系统输出文件，这样就能查看。BODY创建一个打印注册文件，包含AppWorx登录系统输出的所需的信息。

运行扩展脚本

BODY脚本在模块执行的不同时间也运行用户定义的脚本。这些被当作运行扩展。所有合法的shell或批处理脚本都能被当作运行扩展脚本，它必须保存在AW_HOME的exec子目录，并被适当命名。

第一个运行扩展脚本是SYSOUT脚本。在作业运行前，AppWorx执行适当的PREFIX脚本(如存在)。剩余的脚本(COMPLETION, SUCCESS,和 TROUBLE)在程序运行之后运行。

警告！SYSOUT, PREFIX, COMPLETION, TROUBLE 和 SUCCESS脚本都是被在线调用。很差的或不适当的代码可以对AppWorx控制和监测模块的执行产生不利影响。例如，脚本中的‘exit’可以会导致模块的状态改为DIED。

BODY(从程序类型脚本返回)

程序类型完成之后，BODY测模块管理/输出规格定义的“Minimum-Run-Time ”。如果过去的时间低于最低运行时间，然后作业中止和AppWorx设置错误状态等于1 。
BODY运行任何运行扩展脚本（COMPLETION, TROUBLE和SUCCESS）如果它们存在的话。可以创建一个TROUBLE脚本，在结果返回代理之前，设置重置错误状态。
BODY更新作业完成时间，返回代码，并完成状态。经过检查 所有文件已被成功地转移，BODY删除pr和下pm文件。 最后，BODY删除任何其他创建的临时文件。
Master进行下一阶段的工作处理。

4.5. 程序类型

程序类型脚本(程序执行前)

程序类型和其匹配的脚本一般传递par文件的内容给程序。程序类型是一个对象，用于优化开发和维护的效率。 程序类型对象指定程序类型的脚本。程序类型的脚本完成AppWorx和程序执行的联络，并处理程序输出。可以定义多种程序类型。程序类型的脚本都位于AW_HOME目录的exec子目录。

程序类型脚本(程序执行后)

程序完成执行之后，程序类型脚本捕获输出和确保文件被完全登记。

程序和程序类型的交互影响一个特定的任务的执行。一般而言，程序生成并返回退出状态给程序类型脚本。无论是程序或程序类型的脚本都可能会产生输出，这依赖于输出是如何设置的。任何程序写入标准输出的输出将被系统输出文件捕获。如果程序创建任何额外的输出，需要登记到AppWorx ，程序类型的脚本可以调用FILESIZE。

FILESIZE创建一个文件，包含AppWorx登记输出文件所需的信息。缺省地，输出到$file或%file%。如下列表为缺省设置。

输出	UNIX	Windows
Standard out(log file)	$AW_HOME/out/o<job_id>	%AW_HOME\out\o<jobid>.log
Program output	$AW_HOME/out/b.<$job_id>	%AW_HOME\out\o<jobid>.lis

4.6. 程序

程序执行

程序执行，并返回退出状态给程序类型接口脚本和可能创建输出。程序传递状态值给程序类型脚本和执行（可选）错误检查和输出处理。一般而言，程序类型负责登记输出。

标准输出文件

程序的标准输出一般重定向到作业的日记文件，但有些程序类型脚本可能会重定向输出到一个文件。

程序输出文件

程序的输出文件包含程序实际的信息。一个程序可以生成很多程序输出文件。程序输出的缺省的位置是out子目录。