Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

web to 400 communicaiton methods

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • web to 400 communicaiton methods

    What is the best way to for a web application running on NT to communicate with an 830 12 way AS/400 running v4r5? The 400 already has an IP address, and Domino will be running a different web application on the same machine. We want to keep these animals apart. This is not simply a matter of putting existing green screens on the web. This will be a new web application that uses the 400 as the legacy file repository. The web application will need to retrieve data from files and initiate Robot jobs. What is the best way to communicate between NT and the 400 without interfering with the domino application? Also, what userid do the web initiated requests run under on the 400? Any help will be appreciated as I am quite literally fumbling in the dark here. Thanks in advance.

  • #2
    web to 400 communicaiton methods

    Susan, It is hard to make a suggestion with such limited information. What sort of application is this and what resources can you draw on? David Morris

    Comment


    • #3
      web to 400 communicaiton methods

      The existing AS/400 legacy application is a telephone call billing system with HUGE multi-membered files containing tens of millions of records. 90% of it is batch COBOL. (Ugh.) Files are the regular DDS that we all know and love. I believe we will have some intermediate summarized (i.e. smaller) files available for the web application to extract data from. The new web application will be for selected customers to view their account (billing invoice, etc.) via the internet. I realize that NT probably doesn't need to be in between the 400 and the browser, but that decision is dictated by politics so it's pretty well set in concrete. I am not completely certain, but I believe the users will want to be able to download their bill from the web as well. Another complication is that we are also in the process of building a Domino contract processing system that is, or very soon will be, accessible via the Internet. This new NT invoice web application that I am asking about is completely separate from the D omino application. What sort of resources will we draw on? The web site will send a request to the 400 to query a file or perhaps initiate a 400 job and send the results back to the web client. Although some of our files are enormous, we will probably have more reasonable sized summary files available for the web inquiries. Do we need one IP address for the Domino application and another for the NT based invoice loading application? How does NT communicate with the 400? ODBC? Or is there a faster and/or more secure way? What questions do I need to ask the ?e? people who are building this website? What userid do NT website inititated tasks run under when on the 400?

      Comment


      • #4
        web to 400 communicaiton methods

        Susan, I have a unique solution for you that I came up with in Chicago not long ago for an insurance company with a similar setup. I will describe it tomorrow or Saturday. You may end up not using it, but you will definitely admit it's unique and it works. Ralph

        Comment


        • #5
          web to 400 communicaiton methods

          Thanks Ralph! I'll look for you solution.

          Comment


          • #6
            web to 400 communicaiton methods

            Hi Susan, I'll summarize the solution and then drill down to any details you want should the concept interest you. I went to Chicago a few months ago. The situation was the same....info on the AS/400 but the company's website was on NT IIS. The customer also had the Advanced BusinessLink Strategi web server on the AS/400 and there had been a political turf battle over who would do the web serving. Without even serving one page from the AS/400, the NT guys won the political war. I was called in to help the company figure out how to get AS/400 data to the IIS served web pages in real time. ODBC and sockets programming were the only traditional options that anyone knew of, Susan. FTP was out, Java to Java was out (I can hear the howls of protest now - but the M$ guys are into IIS, SQL Server, and CGI via COM drivers- exchanging data with Java on NT which would then communicate with Java on the AS/400 is not of interest to them - anyway it's just a more convoluted way of doing ODBC - they could care less that "J"DBC would run on another platform besides Windows). MQSeries and other transaction messaging systems were considered a complicated, expensive, slow alternative to doing their own sockets programming. But they weren't keen on ODBC and the NT and AS/400 were fighting so they weren't in a mood to collaborate with a sockets protocol. The AS/400 guys also had the Strategi web server installed and wanted to use it. So as I sat there getting briefed on the situation and found out they wanted IIS web pages populated from the AS/400 in real time, I had an idea. The Strategi web server is ready to receive web pages, so what if IIS just forwarded them to Strategi? I asked the NT programmers if they could send a page to the AS/400 from within the IIS CGI. They said it was embarrassingly trivial. I told the AS/400 guys to just act like the pages were coming directly from the customer. It was irrelevant that it passed through IIS first. Actually, as I explained that the AS/400 was still doing web serving but internally and not requiring their production AS/400 to be exposed to the Internet, they saw it as the best of all worlds. All the development on the AS/400 for this project was web development, yet they weren't on the Internet. The IIS guys stayed within web technology to communicate with the AS/400. It was transparent to them. They were happy. They didn't pass images to the AS/400 in web pages sent to the AS/400. We stripped incoming data that served as keys from an IIS web page and sent some web page with that data to the AS/400. Strategi received the web page and invoked RPG servers to process the data, based on configurations for the web pages via Strategi scripting. There was nothing AS/400 specific in the HTML and whatever processing took place was transparent to the IIS guys. One of several web pages on the AS/400 was returned with data or error information to the IIS CGI program, based on what the IIS guys wanted to see. The AS/400 didn't know or care that it was talking to another web server. The IIS web page going out to the customer contained real time data from the AS/400, and they got it as fast as any other web page would be served back to them. They simply populated a web page kicked out of CGI with some data from the incoming IIS web page, and then in turn transferred AS/400 results to an outgoing IIS web page. We did this in one day and put the solution into the test environment. There were some other pieces that they had to do, but they now knew how to glue the systems together. There was no CGI or "e-" programming on the AS/400. The Strategi web server looked up the corresponding script for the web page (x.hsm for x.htm). The script defined what server programs and routines were to be invoked for this web page, and concatenated specified fields from the web page to be placed in a dataq like buffer and then called each server designated in the script. The script also specified what data from the dataq return were to be placed in a web page and sent back. Let me know if you would like any more details on this approach, Susan. Regards, Ralph

            Comment


            • #7
              web to 400 communicaiton methods

              Ralph, Are the the IIS gurus are using the WININET API ? If so then you need to be aware of the default will limit this to support only 4 concurrent connections at one time. There is a regedit "fix" with the warning this breaks the HTTP 1.1 rules. Though so far I havent seen any problems with setting it higher. Its just that I had a client request some help with stress testing their internet applications and this was a very limiting factor especially where the CGI was long running. If they are not using the WININET APIs I would be interested in getting some more details of how they implemented the redirect. Thanks David

              Comment


              • #8
                web to 400 communicaiton methods

                We did this in one day and put the solution into the test environment. There were some other pieces that they had to do, but they now knew how to glue the systems together. There was no CGI or "e-" programming on the AS/400. The Strategi web server looked up the corresponding script for the web page (x.hsm for x.htm). The script defined what server programs and routines were to be invoked for this web page, and concatenated specified fields from the web page to be placed in a dataq like buffer and then called each server designated in the script. The script also specified what data from the dataq return were to be placed in a web page and sent back. So what you've done is created two different web applications, one "wrappering" the other. And so, rather than a simple messaging system to communicate between one web application and the servers, you've instead introduced a second HTML layer, using Advanced BusinessLink. Of course, as you've said, since you have the business servers in place, you could just as easily send the data to them via a message or an RPC or a data queue; but because the political climate didn't find that acceptable, you've got to now synchronize the HTML generated from the AS/400 with the HTML on IIS (for example, all the field names in the forms on the NT box must coincide with the field names expected by the AS/400 side, or else you have to do some conversion in between). Change control has to be an interesting endeavor. Definitely a unique solution to a novel requirement: having to have two dissimilar web servers running simultaneously. Joe src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Java400.net - Java/400 Freeware" align="middle"> Java400.Net - where the AS/400 speaks Java with an RPG accent Home of PBD2.0, the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

                Comment


                • #9
                  web to 400 communicaiton methods

                  Ralph, Thanks so much for the details. Of COURSE I have more questions! :-) " ... there had been a political turf battle over who would do the web serving. Without even serving one page from the AS/400, the NT guys won the political war. ODBC and sockets programming were the only traditional options that anyone knew of, Susan. FTP was out, Java to Java was out (I can hear the howls of protest now - but the M$ guys are into IIS, SQL Server, and CGI via COM drivers- exchanging data with Java on NT which would then communicate with Java on the AS/400 is not of interest to them " This is precisely what I (we) are dealing with. NT is the company standard for a web server, period. The fact that our data is on the AS/400 and the fact that the 400 can be used as a server is irrelavant to the powers that be. We are circumventing the politics by running Domino on our AS/400s and serving up that application on the web. But this latest endeavor of putting customer invoices on the web has already been absorbed by the "E" people, and that means NT. "MQSeries and other transaction messaging systems were considered a complicated, expensive, slow alternative to doing their own sockets programming." We looked at MQSeries too. It's overkill for what we need. "The AS/400 guys also had the Strategi web server installed and wanted to use it. So as I sat there getting briefed on the situation and found out they wanted IIS web pages populated from the AS/400 in real time, I had an idea. The Strategi web server is ready to receive web pages, so what if IIS just forwarded them to Strategi? I asked the NT programmers if they could send a page to the AS/400 from within the IIS CGI. They said it was embarrassingly trivial. I told the AS/400 guys to just act like the pages were coming directly from the customer. It was irrelevant that it passed through IIS first." Is Strategi really needed? Sorry for being so clueless here, but does Strategi run on NT or on the 400? I am guessing it runs on the 400, and if so, can we use NetFinity instead? NetFinity was installed to run with Domino (so that it could communicate better with M$ products like Excel and Word). Can we use NetFinity without interfering with the other (Domino) application? Also, in NT lingo, what do I ask the NT guys for? Will they understand what I want if I tell ask them to "send a page to the AS/400 from within the IIS CGI?" Thanks again, Ralph! Sue.

                  Comment


                  • #10
                    web to 400 communicaiton methods

                    How about Net.Data?

                    Comment


                    • #11
                      web to 400 communicaiton methods

                      Not a redirect, David, and no "connections". Doing the HTTP Posts and Gets (I think that's the right terminology) to the AS/400 web server IP address is not a pervasive connection, just the stateless web server access ala the browser. Pure CGI programming in IIS.....don't know what components or API's they used, but they showed me some code which did a Post and Get. Also, scaling is internal to AS/400 with multiple server programs, not multiple boxes, so there's only one IP address for any NT box to talk to. Again, the original web page with graphics is not redirected to the AS/400. Key data is extracted in IIS CGI and posted to the AS/400 web server. It is just like messaging, but with the HTTP protocol. I confess I never preplanned this solution, it just came to me when crunch time came. Regards, Ralph ------------------------------------------------- Ralph, Are the the IIS gurus are using the WININET API ? If so then you need to be aware of the default will limit this to support only 4 concurrent connections at one time. There is a regedit "fix" with the warning this breaks the HTTP 1.1 rules. Though so far I havent seen any problems with setting it higher. Its just that I had a client request some help with stress testing their internet applications and this was a very limiting factor especially where the CGI was long running. If they are not using the WININET APIs I would be interested in getting some more details of how they implemented the redirect. Thanks David

                      Comment


                      • #12
                        web to 400 communicaiton methods

                        I don't see the coordination between the systems as any more complex as coordinating message layouts. The pages served by the AS/400 web server are defined in one place and stored in IFS. They are independent of the design of the web pages served by IIS. The coordination of web page form field names for the AS/400 web pages is in the CGI in IIS and the Strategi script. Neither the IIS web pages nor the AS/400 RPG server programs are aware of the AS/400 web page particulars. I would view it more as retrieving key transaction data via HTML than wrappering the original web page. The IIS programming also retrieved data from local SQL Server databases and some other programming under NT. The AS/400 data was merged with data from the other processes in real time to serve pages back to the requestor. Thanks, Joe. Ralph -------------------------------------------------------------- Of course, as you've said, since you have the business servers in place, you could just as easily send the data to them via a message or an RPC or a data queue; but because the political climate didn't find that acceptable, you've got to now synchronize the HTML generated from the AS/400 with the HTML on IIS (for example, all the field names in the forms on the NT box must coincide with the field names expected by the AS/400 side, or else you have to do some conversion in between). Change control has to be an interesting endeavor. Definitely a unique solution to a novel requirement: having to have two dissimilar web servers running simultaneously. Joe

                        Comment


                        • #13
                          web to 400 communicaiton methods

                          No, Susan, Strategi is not needed. It is a native AS/400 web server that takes full advantage of the AS/400 unlike the cross platform Domino and Websphere products, but any web server you have in place that can retrieve AS/400 data in real time via any technology will work as it responds to a web page request from the IIS program written by the NT people. The terminology is do a Get from within NT web server processing (in CGI or the equivalent) of a specific web page URL on the AS/400 web server IP address and poulate the form input fields with data recieved in the page being processed. The AS/400 sends the page with data and the NT programmers put that data where they want in the web page being processed in IIS or use it for whatever processing needed to complete the page. This all happens extremely fast. If not, look at a fast AS/400 web server like Strategi. Also, the data is retrieved and processed on the AS/400 with RPG. Again, if it isn't fast, blow off the IBM marketing people and write some real code. Regards, Ralph ------------------------------------------------------------- Is Strategi really needed? Sorry for being so clueless here, but does Strategi run on NT or on the 400? I am guessing it runs on the 400, and if so, can we use NetFinity instead? NetFinity was installed to run with Domino (so that it could communicate better with M$ products like Excel and Word). Can we use NetFinity without interfering with the other (Domino) application? Also, in NT lingo, what do I ask the NT guys for? Will they understand what I want if I tell ask them to "send a page to the AS/400 from within the IIS CGI?"

                          Comment


                          • #14
                            web to 400 communicaiton methods

                            I don't see the coordination between the systems as any more complex as coordinating message layouts. The pages served by the AS/400 web server are defined in one place and stored in IFS. They are independent of the design of the web pages served by IIS. The coordination of web page form field names for the AS/400 web pages is in the CGI in IIS and the Strategi script. Neither the IIS web pages nor the AS/400 RPG server programs are aware of the AS/400 web page particulars. Well, in a PUT request in HTML protocol, data is passed between the browser and the web server via a set of "name=value" parameter pairs. The "name" portion is the name of the field in the HTML form. So, let's say we have an input field named "CustomerNumber" on my AS/400 web page. If this is displayed to a browser, and the user enters a value of "123" into that field, then the data is returned to the web server as "CustomerNumber=123". Now, if an NT program (or any other program, for that matter) were to attempt to emulate an end user and "stuff" a customer number into the appropriate form field, the only way it could do it would be to send the same "name=value" pair to the AS/400 web server. This is what a lot of portal programs do, in effect "wrappering" one HTML web page inside of another. To do this, you have two options: you can name all your fields in your NT web page the same as your fields in the AS/400 web page and just blindly pass data from the browser back to the AS/400, or you can write code to handle each and every NT page that actually pulls out the NT field and "renames" it before sending it to the AS/400. For example, if your field name on the NT box is "Cusno", then in Java, you would do something like: session400.putValue("CustomerNumber", sessionNT.getValue("Cusno")); Nothing particularly difficult, but there's a degree of mapping that's involved here. Not only that, the AS/400 web page should have a 1-to-1 relationship with the NT pages, unless you have some serious mapping algorithms in your NT program. As you say, this is roughly akin to messaging, mapping the fields of the NT page to the fields of a message, except that you now have the limitations of HTML to work around for your messaging. But if it works, it works. I would view it more as retrieving key transaction data via HTML than wrappering the original web page. The IIS programming also retrieved data from local SQL Server databases and some other programming under NT. The AS/400 data was merged with data from the other processes in real time to serve pages back to the requestor. By the way, do these web pages do any posting (that is, does an HTML POST to the AS/400 web server actually update a database)? If not, then I'm even more confused as to why the HTML interface to the AS/400 was needed at all. If you're already doing SQL, then you might as well have chosen stored procedures (note that I'm not a big fan of stored procedures, but for strict query situations they can work nicely). But all of my discussion is based on my bias towards simpler things using as little middleware as possible; your solution is geared more towards the "component" design which takes prefabbed architectural pieces and integrates them into a working solution. As long as the approach works, and is maintainable and scalable, then it's a valid way to go. Joe src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Java400.net - Java/400 Freeware" align="middle"> Java400.Net - where the AS/400 speaks Java with an RPG accent Home of PBD2.0, the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

                            Comment


                            • #15
                              web to 400 communicaiton methods

                              "Nothing particularly difficult, but there's a degree of mapping that's involved here. Not only that, the AS/400 web page should have a 1-to-1 relationship with the NT pages, unless you have some serious mapping algorithms in your NT program. As you say, this is roughly akin to messaging, mapping the fields of the NT page to the fields of a message, except that you now have the limitations of HTML to work around for your messaging. But if it works, it works." Either field names or field offsets have to be coordinated to handle data exchange between two systems. If variable names for HTML form input fields (or whatever web people call them) can be used in the Post and Get syntax of a language, then I would have an externally maintained mapping table to transfer data from field x to field y. In other messaging protocols, the names may be internal, but the offsets for those internal names have to be kept synchronized. That holy grail of messaging, XML, is processed by looking for names that must be kept in synch between two systems. No matter what XML technologies exist for translations, there's nothing that would be done for this situation that a table driven mapping scheme wouldn't handle. As I referred to earlier, there was more going on with the IIS web pages than data retrieval from the AS/400. Only a subset of the fields entered by customers were passed on to the AS/400 for real time processing. Other processing was done at the same time against a local SQL Server database and some local programming. If a particular web page happened to have a one to one correspondence with the AS/400 web page, that was just a coincidence. By the way, what limitation is there in sticking text in an HTML field instead of in a message data structure field? "By the way, do these web pages do any posting (that is, does an HTML POST to the AS/400 web server actually update a database)? If not, then I'm even more confused as to why the HTML interface to the AS/400 was needed at all. If you're already doing SQL, then you might as well have chosen stored procedures (note that I'm not a big fan of stored procedures, but for strict query situations they can work nicely)." The Strategi web server looks up a script file corresponding to the web page name (same_name.hsm instead of htm), concatenates the data from form fields specified in the script, and passes them to a server program specified in the script. The servers sit on a receive dataq like call and wait for input. Server programs can be written in any language, and the jobs web site backend I wrote this year had ILE RPG, RPG III, and Java servers taking calls from web pages and from each other. For example, an opcode I wrote in one ILE server to send e-mail, or any number of other business processes, may have been invoked directly from a web page, another server, or any other AS/400 program for that matter. As you have advocated, Joe, calling RPG server programs leverages code, skills, and speed. The difference here is that the Strategi web server is directed to call a program via a script external to the web page HTML code, versus specifying a Java servlet in the HTML code which may then call an RPG program. It's not the overhead I'm referring to, but the hardcoded logic within the HTML. Pages being served to the public and designed by professionals needn't be clobbered with inserted call logic and version controlled with the web designers. The server programs do business processing as usual on an AS/400. On the one hand, the web pages were for customers and did not require an intense business processing interface, but a friendly customer interface instead. On the other hand, customer order entry and service can require some intense internal business processing if done in real time, as I did. I use record level I/O instead of SQL, but then I also believe in performance versus lowest common denominator technologies. Sending a web page to the Strategi web server and causing an RPG server program to be invoked and then getting the web page response takes two milliseconds on an internal network. It would take some serious I/O or starting up standalone AS/400 programs from the server to slow this reponse down. In addition, neither the web page nor the RPG program have any references to technology in them. The web pages coming from another web server are sparse, generic HTML text with form tags, and the RPG program is a dataq like processor that cases on a message type. There was no SQL involved, no ODBC, no RPC, so there was nothing that leveraged a stored procedure call and made sending a web page an unnatural act. In any event, the Strategi invocation of an RPG server is light years faster than a stored procedure call. "But all of my discussion is based on my bias towards simpler things using as little middleware as possible; your solution is geared more towards the "component" design which takes prefabbed architectural pieces and integrates them into a working solution. As long as the approach works, and is maintainable and scalable, then it's a valid way to go." I consider this use of the web server and Strategi's scripted invocation of server programs to be cleaner than coordinating sockets calls, much more powerful than ODBC and stored procedure calls, and much less complex than messaging middleware like MQSeries. Joe, does your PBD solution require a web server as IBM does with Websphere, a proprietary server as ASNA and Delphi/400 do, an open sockets interface, or what? Ralph

                              Comment

                              Working...
                              X