使用 ECuRep 与 IBM 软件技术支持互相传送文件

使用 ECuRep 与 IBM 软件技术支持互相传送文件

问题

IBM 软件技术支持人员经常会要求提供文件来帮助解决问题,如何使用ECuRep服务来发送或接收文件?

解决问题

ECuRep, Enhanced Customer Data Repository的缩写,是一个用于在IBM支持中心人员和客户之间交换数据的FTP服务器。这个服务与其他FTP相比的优势是当传送文件时,EcuRep会更新PMR(Problem Management Record 问题管理记录)。所以,当有文件提交时,技术支持代表会被及时通知到。
除了使用FTP,客户还能够通过ECuRep邮件网关用电子邮件发送文件。

更多的关于ECuRep的信息,包括发布和邮寄文件的步骤,可以从如下的ECuRep网站上查找。

http://www.ibm.com/de/support/ecurep

在使用ECuRep之前,请阅读关于出口条例和保密性的服务使用协议。

如下提供了使用这个服务的步骤。

使用邮件向ECuRep发送文件

1.协同工作的技术支持代表会提供给你相应的邮件地址。
2.压缩文件。文件格式可参考下面FTP部分。
3.邮件的标题必须遵循统一的命名规则,这样支持工具可以存储邮件和附件到相应的目录并更新PMR,并以此来表明新的数据可以使用。邮件主题行的命名规则如下:

PMR xxxxx bbb ccc text

其中 xxxxx = the PMR ID, bbb = branch office, ccc = 国家代码, text = 文件的描述

例如: PMR 12345 678 000 这里是诊断文件

4. 一旦你的邮件被处理,会收到一封自动的回复.如果邮件标题不遵循上述规则,就无法关联到PMR,就会被标注为遗弃的邮件,最后会被删掉。

使用FTP上传文件

A. 压缩文件.

如果您在向IBM提交电子数据前对其进行压缩,可以节省您的时间。建议使用下列格式之一:

B.文件命名格式 pmr_#,branch_office_#,country_code,desc.type

例子: 34143,055,000,nsd.zip

文件名格式 xxxxx,bbb,ccc,desc.yyy 。文件名上使用逗号,文件名和文件类型中间使用句号。

解释 例子
xxxxx PMR号码 34143
bbb 部门号 055
ccc IBM地区编号 000
desc 文件的简短描述 nsd
yyy 文件类型后缀 zip 或 tar

(可以在 ECuRep站点上找到地区编号列表。例如, 美国是000,中国大陆 672,台湾 858,香港 738。)

注意: 须使用特定的命名规则; 只有使用正确的文件名,PMR才能够自动更新。

C. 使用FTP工具或软件连接 ftp.ecurep.ibm.com。然后,上传文件到”toibm\lotus”目录。对于Domino zSeries的 terse 压缩的数据,上传文件到”toibm\mvs”。

下面给出了使用DOS命令连接和上传文件的步骤

重要提示:

  • 如果使用FTP客户端或工具,例如FileZilla,文件必须以二进制的格式传输.这是成功上传的关键设置之一。
  • 不要使用需要浏览文件夹来允许上传的FTP客户端或工具,为了保密和安全,ECuRep服务器规定要上传到指定的文件夹并且不允许浏览文件夹。
  • 如果连接不上FTP服务器,检查防火墙和其他造成网络问题的设置。
  • 文件上传后不能更改.如果需要发布一个更新的版本,用一个不同的文件名创建并上传一个新文件。

步骤:
1. 在DOS命令行, 进入上传的文件的目录。例如:

C:\> cd ftpput

2. 在DOS命令行, 键入“ftp”和服务器名 ftp.ecurep.ibm.com, 回车。例如:

C:\FTPPUT> ftp ftp.ecurep.ibm.com

3. 有消息提示通知连接到了请求站点。消息中包含了版权信息和匿名连接的指令。

4. 在用户名提示行,键入”anonymous”按回车,例如:

User id: anonymous

5. 在密码提示下,输入邮件地址,例如:

Password: jdoe@example.com

阅读更多

WebSphere Process Server管理器的恢复

本文解释了 WebSphere  Process Server 管理中的一项重要任务 —— 在遭遇不可恢复的灾难后还原部署管理器。

简介

当 WebSphere Process Server 部署管理器突然停止或变得不可恢复时,那么客户机就将陷入危险的境地。您不应该仅仅安装产品并创建配置文件,因为这种现有的拓扑会带来一些具有独特特性的 WebSphere Process Server(此后简称为 Process Server)应用程序。本文给出了一个 WebSphere Process Server 6.0.2.X 部署管理器恢复场景,它将处理 Process Server 提出的挑战。本文还适用于 WebSphere Process Server V6.x。本文介绍了可以帮助您尽可能顺利地完成此过程的流程以及所需的步骤。

前提

您必须在每次成功修改配置后备份部署管理器配置,并集中存储备份配置文件。需要进行备份的配置修改包括:

完成服务器调优

新应用程序部署

在配置、JDBC、JMS MQ 等中添加、修改和删除资源。

WebSphere Process Server 运行时安装

本文将安装 Process Server 运行时并将补丁包应用到安装好的运行时中。要开始恢复过程,首先要将产品安装到新服务器中。

检查新服务器是否拥有和旧服务器相同的操作系统和操作系统补丁,旧服务器就是指部署管理器在出现故障之前在其上运行的服务器。使用相同的操作系统可以确保资源路径名等具有兼容性。

在将托管部署管理器的新服务器上安装产品。

使用用于创建主站点服务器的相同响应文件。

确保 Process Server 安装位置在所有服务器中都是相同的,例如:/opt/IBM/WebSphere/ProcServer

 应用补丁:

确保新的服务器使用与其余节点相同的版本。包括精确的补丁包。参见WebSphere Process Server V6.0.2 Fixpack 4 (6.0.2.4) for V6.0.2 客户。

复制必要的第三方库、属性和文件。

第三方库位置应当匹配主站点服务器的位置,例如 Oracle? JDBC jars 和位置。

根据共享驱动器映射所有的共享目录。确保使用与生产环境相同的驱动器名称和驱动器字母。包括以下例子:

共享日志目录

共享事务日志等

在新服务器上创建部署管理器配置文件

在新服务器上安装好 Process Server 运行时后,下一步是在新服务器上创建部署管理器配置文件。本节将描述匹配现有安装所需的关键信息。注意,不一定要与现有安装完全相同,但是这样做会简化配置恢复过程(配置恢复过程将在下一节介绍)。

在新服务器上创建部署管理器配置文件。确保以下名称匹配初始部署管理器服务器上的配置:

profileName

nodeName

cellName

installLocation

注意:如果可行的话,可以通过更新主机名使用与构建主站点相同的响应文件。这提供了一致性并减少了错误的数量。

检查部署管理器是否已经成功安装。

在新的服务器上恢复 WebSphere Process Server 部署管理器

本节主要关注从备份文件中恢复部署管理器的配置:

将最近的部署管理器配置备份文件复制到新服务器:<DMGR_PROFILE>/WPS_DMGR_PRIMARY_BACKUP_DD_MM_YY.zip

运行 restoreConfig:<DMGR_PROFILE_HOME>/bin/restoreConfig.sh <DMGR_PROFILE> /WPS_DMGR_PRIMARY_BACKUP_DD_MM_YY.zip -username <user_name> -password <password>

如果使用了不同的 cell 名称,那么可能会发出警告,要求您在恢复过程期间使用-force标志。

如果主机名不同的话,使用虚拟 IP 解析获得相同的 DMGR 主机名。有关修改 DMGR 主机名的更多信息,参见WebSphere Application Server V6.0 配置修改最佳实践。

删除以下子目录中的所有内容:

< DMGR_PROFILE_HOME >/wstemp

< DMGR_PROFILE_HOME >/config/temp

在服务器上启动部署管理器:

输入startManager。

观察日志文件并确保部署管理器在 DR Server 1 上正确启动。

同步节点代理

本节将同步现有的节点与新创建的部署管理器。

如果主机名已被修改为新的主机名,那么必须执行这一步骤。

在 wsadmin.properties 中将com.ibm.ws.scripting.host修改为新的主机名:NODE_AGENT_PROFILE_HOME /properties/wsadmin.properties. change to the com.ibm.ws.scripting.host=<NewHostName>

保存文件。

将 Node 代理同步到新的 DMGR Server。

<NODE_PROFILE_HOME>/bin/syncNode (.bat/.sh)<dmgr_host> <dmgr_soap_port> -username <name> -password <password>

观察部署管理器上的日志文件和控制台上的日志文件。

启动节点代理:

<NODE_PROFILE_HOME>/bin/startNode(.bat/.sh)

观察 Node Agent 1 的日志文件,确保它们是良好的,并且日志中没有出现错误。

确保一次只同步一个,不会对 Service SLA 产生影响。

 

BPM是与非-什么是BPM,如何识别是否是BPM产品,以及如何选择BPM产品(3)

如何选择BPM产品

真正的BPM需要提供面向业务人员的业务流程的建模语言、建模工具、管理工具和监控工具;需要屏蔽掉业务人员弄不懂的IT语言与实现;需要强大的集成能力可以贯通分散于各个业务部门各个平台上的异构系统以实现企业整体业务流程管理和绩效监控;还需要业务流程当中的活动可以与企业战略挂钩,使得业务流程的运行直接反馈战略执行状态。

因此,一个真正的BPM软件要解决的是以下一些核心问题:

  1. BPM与其他IT产品要么支持业务用户、要么支持IT建设的不同之处在于,它必须横跨业务和IT两个部分,它必须很好的支持业务用户采用业务语言来建设业务流程;同时它又必须能够支持IT人员使用IT语言来整合IT资产以实现业务流程。这要求一个BPM产品必须同时具备业务设计能力与IT设计能力,并且能够将两种模型统一为一个完整的模型;
  2. 与以前纯IT产品不同,企业的运营流程与BPM产品里的资产应该是高度同步的,这些资产映射了真实的业务流程而不是需要翻译的IT资产。当企业的业务变更发生时,这些变更不需要等待从业务翻译为IT资产的周期,而是由业务人员直接将其转化成BPM资产,这些BPM资产则应快速响应业务变更。这要求一个BPM产品要能够管理一个业务流程(BPM资产)从创建到测试、模拟、部署、运行、监控、改进、变更、升级、归档的整个生命周期;
  3. 与单纯的某一类专业IT产品(如生产、财务、客户关系管理等)不同,BPM更注重于跨部门、跨IT系统、跨业务甚至跨组织的综合业务需求。尽管它在解决企业应用架构中较低层次的执行问题方面也是利器,但BPM的更大的价值在于它能够在整个企业应用架构中更高的层次上整合业务,能够与企业战略相结合。这要求一个BPM产品要能够使用粗粒度的服务来快速构建应用程序而不是从头开发。
  4. BPM整合业务的需求使得BPM必须具备更强的扩展能力,能够容纳、扩展、整合各种各样的企业应用,以BPM为核心形成应用生态圈而不是仅仅是孤立的业务问题和流程问题。这要求一个BPM产品必须基于开放的标准和平台,要能够具备跨平台、跨应用的整合能力,可以扩展和被扩展,以满足企业各种各样的业务需求和应用环境。

以上4个核心问题,同时也是对一个BPM产品对企业业务流程管理支持度的评判,企业可以从以上四个方面来评估一个BPM产品是否符合自身的需要。

但同时需要说明的是, 选择BPM产品并不是一味的越大越全就越好。因为BPM的实施是一个循序渐进的过程,它必须与企业当前的BPM成熟度、业务规模、人员素质等相匹配,同时也与BPM产品的本身的复杂度息息相关。显然,一个刚刚接触并开始采用BPM的企业,不可能完全掌握从战略到执行的建模方法,不可能建立完善的从战略目标到活动的指标体系,也无法在短时间内在管理上疏通各个业务职能部门。直接实施一个庞大的BPM计划,引入一个全面但复杂的BPM产品,将会使企业充满挫败感:每走一步都极为艰难,周期长,难见成效。许多邀请咨询公司做了业务流程梳理但却难以落地的企业对此应深有体会。

因此,在比较各BPM产品如何解决上述的核心问题之外,还需要看该BPM产品的复杂度和针对不同背景和需求的客户的支持程度。其关键是两个方面:

其一,一个BPM产品是否能够支持并帮助企业循序渐进的小步快走,步步为营,步步为赢,在短时间内见成效。每建立一个业务流程都体现出应有的价值,帮助企业建立信心,找到适合自己的方法,锻炼业务流程管理能力,从而最终全面采用BPM。这要求一个BPM产品具备快速实施的能力,并且产品的复杂程度能够针对不同客户量身定制。一个实施过程复杂、无法按需求规模定制复杂度的产品,将会给BPM的实施带来许多额外的困难。

其二,一个BPM产品是否能够支持企业长期的、不断深入的、扩展的业务需求。随着企业使用BPM的成熟度提高,其需求也必将从简单走向复杂、从表面走入深层、从一个业务领域扩展到另一个业务领域。这要求一个BPM产品具备完整的产品体系以及各产品模块的灵活配置、扩展甚至即插即用的能力,以保证不断扩展产品功能的同时维持BPM建设进程的稳定并且保护已有资产。不具备灵活的架构,只能通过定制开发来扩展功能的产品,将无法有效支持此需求。

BPM的实施团队的能力也很重要

BPM的实施与传统管理信息化项目不同,与ERP倒是有几分相似:项目实施过程必然要依据对业务的深刻理解并伴随着业务的改造、优化和调整等活动,而不仅仅是简单的实现当前的业务。这要求实施团队不仅仅要懂IT技术,更重要的是懂业务,要能够跟业务人员在业务层面上进入深入的交流。最理想的BPM实施团队要有业务流程梳理的知识与技能,有实施企业业务管理的经验,能够帮助客户量身定制的寻找和定位业务价值、定义业务能力、端到端的建模业务流程并且能够找出流程中的瓶颈并且与客户一起寻找到适合该企业的优化的办法。

再好的BPM产品交到只懂技术,持有技术至上观点或者只会用IT思维去思考业务问题的团队去实施,其结果必然会失败。因为BPM是业务驱动而非IT驱动的,成功的BPM绝不仅仅是几个流程跑起来,解决了当前问题就完事。而是通过BPM的建设,从纵向打通企业自顶向下的价值实现过程(从战略目标或业务价值到业务执行),从横向建立价值实现能力(跨部门、跨业务的业务能力),从环向上建立业务绩效评估(业务活动针对某业务价值的指标监控)体系,最后通过BPM产品的业务流程治理来不断的优化上述的各个管理要点,从而不断的提升企业的价值创造能力。这些实施目标与技术相关不大或说技术只是支持,与BPM实施团队的业务理解能力、行业领域知识和行业管理咨询经验则是息息相关。

因此对有志于实施BPM的企业来说,除了关注BPM产品本身,还需要关注BPM实施团队的业务能力和业务经验,毕竟BPM绝不仅仅是一个IT级别的产品。从这一点来说,大、中型企业的业务往往错综复杂,规模也要大得多。要想成功实施BPM,与具有丰富业务经验和行业管理咨询能力的BPM产商合作是更好的选择。一个实施团队实施了BPM,但又不能够在业务管理咨询方面向客户输出行业的成功经验、提供行业解决方案和量身定制的业务领域模型并因地置宜的提出优化建议,最终很可能成为只是实现了局部的、片断化的、仅仅实现了当前业务的所谓的BPM。这一结果距离真正的BPM成功尚有相当的差距!!可能只是披了流程外壳的传统信息化,或者新瓶装旧酒的又一个OA、工作流系统而已。