【问题标题】:Best practices when communicating with AS400 (IBM i) from .NET从 .NET 与 AS400 (IBM i) 通信时的最佳实践
【发布时间】:2017-04-26 04:10:27
【问题描述】:

在现有的基于 AS400 的系统之上构建基于 .NET 的报告解决方案时,我需要一些重要的和最佳实践方面的帮助。

  • 什么是最适合的集成 技术(ODBC、OLE DB、ADO.NET) 这取决于什么版本 我们正在谈论的AS400?是吗 总是 DB2 数据库或那样做 变化到?通常使用哪些其他持久性系统?
  • 是否可以调用 大型机中的程序 它们中的逻辑,或者最好在 .NET 层中复制该逻辑 然后直接调用大型机DB?
  • 我想报告系统应该在线并直接调用大型机数据库,还是有其他首选方式(例如文件导出等)?
  • 在开始项目(AS400 版本等)之前需要了解哪些技术细节以消除问题。

基本上,我对 .NET/AS400 项目的所有信息和经验都感兴趣(并将投票赞成)。我以前从未这样做过,需要在项目开始之前了解其中的陷阱。

【问题讨论】:

    标签: .net ibm-midrange


    【解决方案1】:

    好吧,几年前我曾经使用和连接到 .NET 的 AS/400 和大型机系统。我可能无法直接回答你的问题,但我可以让你知道什么对我有用,以及我过去做过的一些事情。

    此类工作的常用术语是Enterprise Application Integration (EAI),因此您可以先阅读它。据我所知,在 AS/400 上可能不仅有 DB2 数据库。我们使用绿屏(或旧版)应用程序有两种方式:

    1. 直接访问数据源/存储
    2. 创建会话,发送诸如 F10、F4 等旧版应用程序用于在不同屏幕中导航的击键,并从旧版屏幕上的固定点抓取数据(这有时称为屏幕抓取)。

    为了部分回答您的第一个问题,为了直接访问数据源,我们使用当时 2 家公司提供的 ODBC 驱动程序创建了 DSN(数据源名称),Rumba(由 Wall Data 制造)和 Attachmate(由我认为是 IBM)。要创建 ODBC DSN,您通常进入管理工具/数据源并添加系统 DSN。您将需要(旧系统)主机名、用于登录的用户名和密码。然后,我们在 .NET 应用程序中使用这些 DSN 来创建与旧应用程序的连接。如果您有 DSN,则可以使用 SQL Server DTS/SSIS 之类的工具从源中获取数据并将其保存在某个位置,无论是数据库、CSV 文件、Excel 文件等。它也很有可能拥有报告工具 (Crystal/SQL Server Reporting Services) 直接使用 DSN 访问数据源,因此您可以直接从数据源报告。您也可以创建无 DSN 连接,几年前我们需要 DSN。

    要部分回答您的第二个问题,如果您愿意,可以调用并使用绿屏应用程序上的逻辑。绿屏通常分为一定数量的行和列,我们使用称为 HLLAPI 的标准将击键从 Windows 系统发送到旧屏幕上的位置。我们为此使用了 Rumba,它可以作为 OCX 控件使用,我相信 Attachmate 也是。例如,您可以创建一个带有用户 ID 和密码文本框的 Winforms 表单,然后创建与旧版应用程序的会话,通常第一个屏幕是登录屏幕。然后使用绿屏上用户名和密码字段的位置将用户 ID 和密码发送到这些位置,然后发送 Enter 击键或登录所需的任何内容。然后,您可以导航到另一个屏幕,例如搜索屏幕,发送数据和击键以执行搜索,然后从绿屏中获取结果数据。另一种方法是创建复制绿屏应用程序并直接从数据存储中获取数据的 Win/Web 表单。这样做的好处是您不必知道旧应用程序的击键/导航,这对于大型绿屏系统来说可能会变得很麻烦。没有对错,要看具体情况。我们公司两者兼而有之。

    对于您的第三个问题,这取决于您想要的报告类型。如果它们需要实时,那么您可以直接连接到数据存储。如果它们不需要实时,您可以每晚从旧系统传输数据并将数据存储在 SQL Server 中,然后针对 SQL Server 数据运行报告。

    您的第 4 个问题的一个答案是,您肯定需要接触了解绿屏应用程序的人。您将花费数小时浏览旧版应用程序的屏幕,因此访问知道系统的用户至关重要。您还需要登录 ID 和密码等。

    最后有一些 3rd 方公司专门将数据从源传输到目标,我最想到的一个是 Data Mirror。另一种方法是使用像 BizTalk 或 Tibco 这样的中间层集成产品,这两种产品都从一个或多个来源获取数据并将它们粘贴到一个或多个目的地,但这可能会根据您的要求而过大。

    希望能有所帮助,祝你好运:)

    【讨论】:

      【解决方案2】:

      如果您不熟悉 OS/400,请为陡峭的学习曲线做好准备。尝试使用本地 AS/400 向导来减轻痛苦,这对于编写奇怪的 CL 程序、获得授权等都是必不可少的。

      就我个人而言,我总是使用 Client Access 提供的 ODBC 驱动程序,但仅限于只读。我无法证明这一点,但十年的 AS/400 编程经验告诉我,尝试从 AS/400 外部更新 AS/400 数据库是一个坏主意。

      确实可以从您的 .NET 应用程序中调用 AS/400 CL 程序,并且如果业务逻辑已经在那里编程,那么使用它是有意义的;在 .NET 中重新发明它成本高昂、容易出错并且速度会慢得多。

      报告消息相同:如果可能,请使用现有消息。

      注意事项(其中一些可能已经过时):

      DB2 SQL 与其他 SQL 方言有许多细微的差别。许多 DBMS 将接受

      SELECT X, Y FROM A, B WHERE A.T=B.T
      

      相当于

      SELECT X,Y FROM A INNER JOIN B ON A.T=B.T
      

      DB2 可能会或可能不会看到它,这取决于表。如果没有,前者可能会很慢。也就是说,如果您遇到性能问题,可以使用一些非常灵活的工具来分析 DB/2 查询计划;您需要您的 AS/400 向导才能使用它们,尽管它们有点晦涩。

      如果您处于国际环境中,则需要小心处理代码页。 确保所有您的 AS/400 具有相同的系统代码页。

      如果您处于多 AS/400 设置中,请注意可以透明地访问本地和远程表(通过直通)。

      OS/400 具有广泛向后支持的悠久历史。只要与您交谈的所有 AS/400 都在同一个主要版本上,您通常根本不必担心版本。它也是一个非常稳定的平台;操作系统错误非常少见,而且很快就能修复。

      如果您可以管理它,请访问具有*ALLOBJ 权限的测试系统。这将使您能够专注于手头的问题并在以后处理安全问题。

      HTH

      【讨论】:

        【解决方案3】:

        我使用客户端访问(现在叫什么)驱动程序连接到我认为基于 ADO.NET 的服务器。通过我拥有的驱动程序版本(我们在 V5R4 上),您不能也必须创建存储过程来调用程序(这并不难)。我以为我听说最新版本可以执行程序,但我不确定。

        我唯一要看的另一件事是创建一个用户,该用户只有您需要做的事情,以防有人获得该用户名和密码,他们不能做太多。我们设置了一个只读 (*USE) 用户和一个 rwx (*CHANGE) 用户。

        【讨论】:

          【解决方案4】:

          [抱歉没看到这是旧帖。希望它仍然有用]

          我编写了绿屏和 .Net 应用程序。根据我的经验..

          1。 ODBC - 有效,但您需要在所有用户 PC 上设置 ODBC 设置。 .NET 数据提供程序更好,因为里面有更多.net 特定的东西,不需要在所有客户端设置 ODBC 设置。在 as400 中提供 .net 提供程序之前,我主要使用 OLEDB。详情请参考http://www-03.ibm.com/systems/i/software/access/windows/dotnet/

          2.使用存储过程。存储过程通常比将所有逻辑放入 .net 更快。创建用 RPG、CL、COBOL、C++ 等编写的 SQL 或外部存储过程...程序

          3. 对于报告,再次使用传递回结果集的存储过程。它快速、干净并且与 Crystal Report 配合得很好。

          4.技术细节。如果您有许多客户端要安装该程序 - 使用 Web 服务 - 您不必在所有 PC 上安装正确版本的 Client Access。

          观看您的 OS400 版本。 如果使用 OS400 版本 V6R1 及更高版本,请确保使用的客户端访问是 V5R4 或更高版本 - 存储过程可能无法在较旧的客户端访问中正常工作。

          ODBC 适用于较旧的客户端访问,但我认为 .NET 数据提供程序仅适用于 V5R3。

          如果您使用 .NET Data Provider V6R1 编译 .net 程序,那么您的用户客户端访问权限也必须是 V6R1。

          出于安全考虑,尽可能使用存储过程(不需要暴露表)并简化程序逻辑(可以重复使用 RPG 程序)

          在 OS400 端,确保系统值 QCCSID 设置为正确的 CCSID,例如37 英语。 ODBC、OLEDB、.net 驱动程序会自动将正确的字符转换/翻译成您的 .Net 程序。切勿将值保留为 65535。

          希望这会有所帮助。

          【讨论】:

          • 在没有经过重要测试的情况下,不要从 65535 更改系统值 QCCSID。虽然如果网络很重要,最好不要在 65535 下运行系统,但有些系统的应用程序设置为依赖它。
          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 2017-03-18
          • 1970-01-01
          • 2023-04-08
          • 2015-06-05
          • 2012-08-28
          • 2015-07-23
          • 2010-09-23
          相关资源
          最近更新 更多