與.NET中的AS400 (IBM i)通信時的最佳實踐

[英]Best practices when communicating with AS400 (IBM i) from .NET


I need some help on what's important and best practices when building a .NET based reporting solution on top of an existing AS400 based system.

在現有的基於AS400的系統之上構建基於。net的報告解決方案時,我需要一些關於什么是重要的和最佳實踐的幫助。

  • What's the most suited integration technology (ODBC, OLE DB, ADO.NET) and does that depend on what version of AS400 we're talking about? Is it always DB2 databases or does that vary to? What other persistency system are usually used?
  • 什么是最適合的集成技術(ODBC、OLE DB、ADO.NET),這取決於我們正在討論的AS400版本嗎?它總是DB2數據庫,還是會隨其變化?通常使用什么其他持久性系統?
  • Is it possible to call programs in the mainframe that has logic in them or is preferable to replicate that logic in the .NET layer and then call the mainframe DB directly?
  • 是否有可能在大型機中調用包含邏輯的程序,或者最好在.NET層中復制該邏輯,然后直接調用大型機DB ?
  • I guess a reporting system should be online and call the mainframe DB directly or are there other ways (for example file export etc.) that would be preferred?
  • 我想報告系統應該是在線的,直接調用大型機DB,還是有其他更好的方式(例如文件導出等)?
  • What technical details are important to find out before starting the project (AS400 version etc.) to eliminate problems.
  • 在開始項目(AS400版本等)之前,什么技術細節是重要的,以消除問題。

Basically I'm interested (and will vote up) in all information and experiences from .NET/AS400 projects. I've never done it before and need to know the pitfalls before project start.

基本上,我感興趣(並且將會投票)所有的信息和經驗。net / as400項目。我以前從來沒有做過,在項目開始之前我需要知道這些陷阱。

4 个解决方案

#1


2  

If you're not familiar with OS/400, be prepared for a steep learning curve. Try and reduce the pain by enlisting the local AS/400 wizard, it will be indispensable for writing the odd CL program, getting authorisations etc.

如果你不熟悉OS/400,准備好面對一個陡峭的學習曲線。嘗試通過注冊本地AS/400向導來減少痛苦,這對於編寫奇數CL程序、獲得授權等都是必不可少的。

Personally I always stayed with the ODBC drivers supplied with Client Access, but only for read-only. I can't justify this, but a decade of AS/400 programming taught me that trying to update an AS/400 database from outside the AS/400 is a bad idea.

就我個人而言,我始終與提供客戶端訪問的ODBC驅動程序保持一致,但僅限於只讀。我無法證明這一點,但十年的AS/400編程讓我認識到,試圖從AS/400之外更新AS/400數據庫是一個壞主意。

It is indeed possible to call AS/400 CL programs from your .NET app and, if the business logic is already programmed there, then using it makes sense; re-inventing it in .NET is expensive, error-prone and will be much slower.

確實有可能從。net應用程序調用AS/400 CL程序,如果業務邏輯已經在那里編程,那么使用它是有意義的;在。net中重新發明它是昂貴的、容易出錯的,而且速度會慢得多。

Same message for reporting: use the existing ones if possible.

報告的消息相同:盡可能使用現有的消息。

Things to look out for (some of these may well be outdated):

需要注意的事情(其中一些很可能已經過時了):

DB2 SQL has many subtle differences to other SQL dialects. Many DBMSs will accept

DB2 SQL與其他SQL方言有許多微妙的區別。許多dbms將接受

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

as equivalent to

相當於

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

DB2 may or may not see it, depending on the tables. When it doesn't, the former can be very slow. That said, if you have a performance issue, there are some very slick tools to analyse the DB/2 query plans; you'll need your AS/400 wizard to use them though as they're a little obscure.

DB2可能會看到,也可能看不到,這取決於表。如果沒有,前者可能會很慢。也就是說,如果您有性能問題,有一些非常靈活的工具可以分析DB/2查詢計划;您需要您的AS/400向導來使用它們,盡管它們有點晦澀。

If you're in an international environment, handling code-pages needs care. Make sure all your AS/400s have the same system codepage.

如果您在一個國際化的環境中,處理代碼頁需要小心。確保所有的AS/400s都有相同的系統代碼頁。

If you're in a multi-AS/400 setup, be aware that local and remote tables can be accessed transparently (with passthrough).

如果您在一個多as /400設置中,請注意,可以透明地訪問本地和遠程表(通過passthrough)。

OS/400 has a long history of extensive backward support. You will generally not have to worry about versions at all, as long as all the AS/400s you are talking to are on the same major release. It is also a very stable platform; operating system bugs are very rare and quickly fixed.

OS/400有着廣泛的落后支持的悠久歷史。您通常不需要擔心任何版本,只要與您交談的所有as /400s都在同一個主要版本中。它也是一個非常穩定的平台;操作系統錯誤是非常罕見的,並且可以快速修復。

If you can manage it, get access to a test system with *ALLOBJ privilege. This will allow you to focus on the problem at hand and deal with the security issues later.

如果您可以管理它,那么可以使用*ALLOBJ特權訪問測試系統。這將使您能夠專注於手頭的問題,並在稍后處理安全問題。

HTH

HTH

#2


3  

Ok I used to work with and connect to AS/400 and mainframe systems from .NET several years ago. I might not be able to answer your questions directly but I can let you know what worked for me and some of the stuff I did in the past.

幾年前,我曾在。net工作並連接AS/400和大型機系統。我可能無法直接回答你的問題,但我可以告訴你什么對我有用,以及我過去做過的一些事情。

A common term for this type of work is Enterprise Application Integration (EAI) so you could start by reading up on that. As far as I know it is possible to have more than just DB2 databases on AS/400s. There were 2 ways in which we worked with green screen (or legacy) applications:

這種類型的工作的一個常見術語是企業應用程序集成(Enterprise Application Integration, EAI),因此您可以從閱讀它開始。據我所知,有可能不僅僅是使用DB2數據庫作為/400s。我們使用綠屏(或遺留)應用程序有兩種方式:

  1. Access the data source/stores directly
  2. 直接訪問數據源/存儲
  3. Create a session, send keystrokes such as F10, F4 etc. that the legacy app uses to navigate through different screen, and grab data from fixed points on the legacy screen (this is sometimes called screen scraping).
  4. 創建一個會話,發送諸如F10、F4等按鍵,這是遺留應用程序用來在不同的屏幕上導航,並從遺留屏幕上的固定點抓取數據(有時稱為屏幕抓取)。

To partially answer your first question, to access the data sources directly we created DSNs (data source name) using ODBC drivers which were available from 2 companies at the time, Rumba (made by Wall Data), and Attachmate (made by I think IBM). To create an ODBC DSN you typically went into Admin Tools/Data Sources and added a system DSN. You would need the (legacy system) host name, user name to log on with and password. We then used these DSNs inside .NET apps to create a connection to the legacy apps. If you have a DSN you can then use something like SQL Server DTS/SSIS to grab data from the source and save it in some location, whether that be the database, CSV files, Excel files etc. It's also more than likely possible to have a reporting tool (Crystal/SQL Server Reporting Services) access the data source directly using the DSN so you could report directly from the data source. Also you could probably create DSN-less connections as well, years ago we needed DSNs.

為了回答第一個問題,我們直接訪問數據源,我們使用ODBC驅動程序創建了DSNs(數據源名稱),這些驅動程序是由當時的兩家公司提供的,Rumba(由Wall data制作)和Attachmate(我認為是IBM做的)。為了創建一個ODBC DSN,您通常會進入管理工具/數據源,並添加一個系統DSN。您需要(遺留系統)主機名、要登錄的用戶名和密碼。然后,我們在。net應用程序中使用這些DSNs來創建與遺留應用程序的連接。如果你有一個DSN然后您可以使用類似於SQL Server DTS / SSIS抓住數據從源並將其保存在某些位置,不管是數據庫,CSV文件、Excel文件等,也更可能報告工具(水晶/ SQL Server reporting Services)直接訪問數據源使用DSN所以你可以直接從數據源匯報。同樣,您也可以創建沒有dtd的連接,多年前我們需要dsn。

To partially answer your 2nd question it is possible to call and use the logic on green screen apps if you want to. A green screen is typically divided into a set number of rows and columns, and we used a standard called HLLAPI that sent keystrokes from a Windows system to positions on a legacy screen. We used Rumba for this which was available as an OCX control and I'm sure Attachmate is also. For example you could create a Winforms form with User ID and password text boxes, then create a session to the legacy app, and usually the first screen would be a logon screen. Then using the positions of the user name and password fields on the green screen send the User ID and password to those positions, and then send an Enter keystroke or whatever was needed to log on. You could then navigate to another screen e.g. a search screen, send the data and keystrokes to perform a search, then grab the resulting data from the green screen. Another approach is to create Win/Web forms that replicate the green screen app and get data from the data stores directly. The advantage of this is that you don't have to know the keystrokes / navigation of the legacy application which could get cumbersome for a large green screen system. There's no right or wrong it depends on the circumstances. Our company did a mixture of both.

要部分回答你的第二個問題,如果你願意的話,可以在綠色屏幕應用程序上調用並使用邏輯。一個綠色的屏幕通常被划分為一組行和列,我們使用了一個名為HLLAPI的標准,該標准將Windows系統的擊鍵發送到遺留屏幕上的位置。我們使用了倫巴作為OCX控件,我相信Attachmate也可以。例如,您可以使用用戶ID和密碼文本框創建Winforms表單,然后為遺留應用程序創建會話,通常第一個屏幕是登錄屏幕。然后使用綠色屏幕上的用戶名和密碼字段的位置將用戶ID和密碼發送到這些位置,然后發送一個輸入鍵擊或任何需要登錄的內容。然后,您可以導航到另一個屏幕,例如一個搜索屏幕,發送數據和擊鍵來執行搜索,然后從綠色屏幕獲取結果數據。另一種方法是創建Win/Web表單來復制綠色屏幕應用程序,並直接從數據存儲中獲取數據。這樣做的好處是,您不必知道遺留應用程序的擊鍵/導航,對於大型的綠色屏幕系統來說,這些操作會變得很麻煩。沒有對錯,這要視情況而定。我們公司把這兩者結合起來。

For your third question it depends on the type of reports you want. If they need to be real time then you can connect directly to the data store. If they don't need to be real time you could do nightly transfers of the data from the legacy system and store the data in SQL Server for example, then run your reports against the SQL Server data.

第三個問題取決於你想要的報告類型。如果它們需要實時,那么您可以直接連接到數據存儲。如果它們不需要實時,您可以從遺留系統進行數據的夜間傳輸,並將數據存儲在SQL Server中,然后針對SQL Server數據運行報表。

One answer for your 4th question is that you will definitely need to get your hands on someone that knows the green screen application. You will be spending hours and hours going through the screens on the legacy app so access to user(s) that know the system is crucial. Also you will need logon id and passwords etc.

對於你的第四個問題的一個答案是,你肯定需要找到一個熟悉綠屏應用程序的人。你將花費數小時的時間瀏覽遺留應用程序的屏幕,以便訪問那些知道系統至關重要的用戶。您還需要登錄id和密碼等。

Finally there are some 3rd party companies that specialise in transferring data from source to destination, one off the top of my head is Data Mirror. Another approach would be to use a middle tier integration product like BizTalk or Tibco, both of which take data from one or more sources and stick them in one or more destinations, but this may be overkill depending on your requirements.

最后,有一些第三方公司專門從事從源到目的地的數據傳輸,我腦海中浮現的一個就是data Mirror。另一種方法是使用中間層集成產品,如BizTalk或Tibco,這兩種產品都從一個或多個源獲取數據並將它們粘在一個或多個目的地,但這可能會超出您的需求。

Hope that helps and good luck :)

希望這對你有幫助,祝你好運。

#3


2  

I use the Client Access (of whatever it's called now) drivers to connect to the server which I believe are based on ADO.NET. Through the version of the driver I have (we are on V5R4), you cannot and would have to create stored procedures to call the programs (which isn't hard). I thought I heard on the latest version you can execute programs, but I am not certain.

我使用客戶端訪問(不管它現在叫什么)驅動程序連接到服務器,我相信這是基於ADO.NET的。通過我擁有的驅動程序版本(我們在V5R4上),您不能也必須創建存儲過程來調用程序(這並不難)。我想我聽說最新的版本可以執行程序,但我不確定。

The only other thing I would look at is creating a user with only the authorities you need to do what you need to do in case someone gets a hold of that username and password, they cannot do too much. We had setup a read-only (*USE) user and a rwx (*CHANGE) user.

我要考慮的另一件事是創建一個用戶,它只有權限,如果有人獲得用戶名和密碼,你需要做什么,他們不能做太多。我們設置了一個只讀(*USE)用戶和一個rwx (*CHANGE)用戶。

#4


0  

[Sorry did not see that this is an old post. Hope its is still useful]

對不起,我沒看到這是一個舊帖子。希望它仍然有用

I have written both green screen and .Net applications. From my experience..

我已經編寫了綠屏和。net應用程序。從我的經驗. .

1. ODBC - works but you need to set ODBC settings at all user PC. .NET Data Provider is better due to more .net specific stuffs inside and don't need to set ODBC settings at all clients. Before .net provider available in as400, i mostly use OLEDB. Refer to http://www-03.ibm.com/systems/i/software/access/windows/dotnet/ for details

1。ODBC -可以工作,但是您需要在所有用戶PC上設置ODBC設置。net數據提供程序更好,因為其中包含了更多。net特定的內容,並且不需要在所有客戶機上設置ODBC設置。在.net提供程序在as400中可用之前,我主要使用OLEDB。詳情請參閱http://www-03.ibm.com/systems/i/software/access/windows/dotnet/

2.Use stored procedures. Stored procedures normally faster than putting all logics inside .net. Create either SQL or external stored procedure written in RPG,CL,COBOL,C++,etc... I don't re-write all RPG old logic in .net, i just change old RPG program little bit and make it into External stored procedure

2。使用存儲過程。存儲過程通常比在。net中放入所有邏輯要快。創建用RPG、CL、COBOL、c++等編寫的SQL或外部存儲過程。我沒有在。net中重寫所有的RPG舊邏輯,我只是稍微修改一下舊的RPG程序,把它變成外部存儲過程

3.For reports, again use stored procedures that passed back result sets. Its fast, cleaner and works well with Crystal Report.

3所示。對於報表,再次使用傳遞回結果集的存儲過程。它的快速,清潔和工作良好的晶體報告。

4.Technical details. If you have many clients to install the program - use Web Services - you don't have to install Client Access with correct version at all PCs.

4所示。技術細節。如果你有很多客戶端來安裝程序-使用Web服務-你不必在所有的pc上安裝正確版本的客戶端訪問。

Watch your OS400 version. If using OS400 version V6R1 and above, make sure client access used is V5R4 or higher - Stored procedures might not works well in older Client Access.

看你OS400版本。如果使用OS400版本V6R1或以上版本,請確保使用的客戶端訪問是V5R4或更高版本——在舊的客戶端訪問中,存儲過程可能不能正常工作。

ODBC works in older client access but i think .NET Data Provider only works in V5R3.

ODBC在老客戶端訪問,但我認為。net數據提供者只在V5R3中工作。

If you compile .net program using .NET Data Provider V6R1, then you user client access also have to be V6R1.

如果您使用。net數據提供程序V6R1編譯。net程序,那么您的用戶客戶端訪問也必須是V6R1。

Use Stored Procedure whenever possible for security (don't need to expose tables) and simplify program logic (can re-use RPG program)

盡可能使用存儲過程來保證安全性(不需要公開表)並簡化程序邏輯(可以重用RPG程序)

On OS400 side, make sure system value QCCSID is set with proper CCSID e.g. 37 for English. ODBC,OLEDB, .net driver will automatically convert/translate proper character to your .Net program. Never leave the value as 65535.

在OS400方面,確保系統值QCCSID與適當的CCSID(如英語中的37)一起設置。ODBC、OLEDB和。net驅動程序會自動地將適當的字符轉換成。net程序。不要將值保留為65535。

Hope this helps.

希望這個有幫助。


注意!

本站翻译的文章,版权归属于本站,未经许可禁止转摘,转摘请注明本文地址:https://www.itdaan.com/blog/2010/11/14/4df76e89c5eb826dc8b8e052de4d5c0d.html



 
粤ICP备14056181号  © 2014-2020 ITdaan.com