1 / 273

WebClient Extensions in 9.1C

WebClient Extensions in 9.1C. Bryan Mau June 22, 2001. Agenda. What’s New in 9.1C Overview Details Migrating from 9.1B Troubleshooting. Agenda. What’s New in 9.1C Overview Details Migrating from 9.1B Troubleshooting. What’s New in 9.1C?. New “IntelliStream” technology for app:

sen
Télécharger la présentation

WebClient Extensions in 9.1C

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. WebClient Extensions in 9.1C Bryan Mau June 22, 2001

  2. Agenda • What’s New in 9.1C • Overview • Details • Migrating from 9.1B • Troubleshooting

  3. Agenda • What’s New in 9.1C • Overview • Details • Migrating from 9.1B • Troubleshooting

  4. What’s New in 9.1C? • New “IntelliStream” technology for app: • Don’t have to download whole app front end at once (“at startup” components vs “as needed”) • Faster, smaller updates (new update paradigms possible!) • Download app code through AppServer pipe • Digitally signed apps • Assembler tool for application deployer

  5. What’s New in 9.1C • Ease of use for ISV: • Easier for ISV to prepare app for WebClient deployment • InstallShield no longer necessary

  6. What’s New in 9.1C • What’s new architecturally? • WebClient Assembler replaces PROWCAPP Editor -- new, central tool for ISV • WebClient now can download/install application code • System Tasks piece of WebClient front end to handle OCX registration, shortcuts etc

  7. What’s New in 9.1C • We still support 9.1B-style app install • Auto convert 9.1B PROWCAPP file to 9.1C PROWCAPP file in Assembler (but no automatic IntelliStream functionality) • Although WebClient downloads application files from AppServer, PROWCAPP file still comes only from Web server

  8. Update Intelligence • When ISV creates a new version of app, we take care of figuring out which files have changed, collecting them into “diff” file • If individual .r file (or other file) from procedure library changes, we detect that and end user downloads only the new .r file (doesn’t have to download whole .pl file)!

  9. New Update Paradigm? • Because updates are smaller (and we automatically take care of a lot of work)… • ISV can (in the extreme) post a new version every night, with the bugfixes or enhancements from that day’s development • Then the end user who starts the app every morning always runs with the latest bits!

  10. Refresher--9.1B Web Install • For good OOBE: bootstrap HTML file • Launches WebClient install • ISV customizes to launch app install after WebClient install • App install runs (e.g. InstallShield OneClick) • App runs

  11. 9.1C Web Install • All still the same (including bootstrap HTML) except: • WebClient can install the app (no need for OneClick) • Linking the WebClient install to the app install involves modifying a small HTML file • No changes in WebClient install itself in 9.1C--new ways to install application

  12. 9.1C CD Install • Still recommend InstallShield for CD install • Can then use IntelliStream for updates! • Mixed mode: some users CD, some Web: • Web install can be: • IntelliStream • OneClick (based on same InstallShield project as CD install) • IntelliStream for updates

  13. Changes in 9.1C • No more “fixins” (pieces used to make the WebClient install). Not needed--ISV can customize (for good OOBE) using WebClient.htm, to tell WebClient install to kick off app install (via prowcini) • webinst.exe becomes webinstall/setup.exe

  14. Caveats • Despite the name “IntelliStream”, we do NOT DO STREAMING in the same way that “Web radio” does. When we’re downloading something, the end user waits--no background downloading while we’re doing something else • IntelliStream not available in other Progress clients--only WebClient (maybe future?)

  15. Caveats • No support for FTP protocol in IntelliStream (only: FILE:, HTTP(S): and APPSERVER:)

  16. Hosting App Code • Web server (as in 9.1B), or • AppServer (either the same one as used for running the app, or different one) • Can share AppServer connection and/or authentication info for “as needed” components and running the app

  17. Changes on AppServer Side • No WebClient-related changes to server side in 9.1C, except: • One new file on AppServer machine: $DLC/WCADD/_GetAppServerFiles.r

  18. Changes on AppServer Side • _GetAppServerFiles.r: • Same file runs on UNIX & Windows (no U/I) • Installed w/ 9.1C AppServer • To run WebClient w/ 9.1B AppServer, must copy this file (see release note instructions)

  19. Sample App Changes • There is an IntelliStream-ed version of Sports2000 (as well as original, non-WebClient version) • Configuration of WebClient version on ProVision CD has changed somewhat from 9.1B

  20. Agenda • What’s New in 9.1C • Overview • Details • Migrating from 9.1B • Troubleshooting

  21. Agenda • Overview • Architecture • Assembler • End User Machine • Security • Migrating to WebClient

  22. Architecture Diagram InternetorIntranet Progress RDBMS Application DeliveryServer Application DevelopmentPC Front End Components Front End Components + Config File + Config File Application Server End User PC AppServer Calls (RUN)

  23. The Sites • End User PC: runs WebClient • Application Server: UNIX, PC, etc • Application Delivery Server: • Web server, or • Application server (9.1C)--can be same • Application Development PC: • Application development • Preparing application for WebClient

  24. The Players: What Do They Do? • Deployer (on development PC): • Prepares application for WebClient • Copies front end component files (and configuration file) to delivery server • End user (on end user PC): • Downloads WebClient and application front end • Runs application (makes AppServer calls)

  25. What’s on the Delivery Server(s)? • Codebase • Application files (.r, .ocx, .pl, etc) that go onto end user machine • May have install set of files and update set of files • Application Configuration File • May be on a different machine • Must be on a Web server (not AppServer)

  26. Application From the AppServer • RUN statements go to an AppServer • Components can come from same AppServer • Maybe easier configuration • Single sign-on (same authentication info for installing, updating & running app) • May even share same AppServer connection

  27. Architecture w/ AppServer Delivery InternetorIntranet Progress RDBMS WebServer Application DevelopmentPC Config File Config File Application Server End User PC Front End Components AppServer Calls (RUN) + Front End Components

  28. Web Server Not Required • For Intranet/LAN scenario, don’t need Web server to distribute that application • Can put Application Configuration File and codebase on file server • Reference URL’s: • FILE://M:/directory (where M is mapped drive)

  29. Agenda • Overview • Architecture • Assembler • End User Machine • Security • Migrating to WebClient

  30. Agenda • Overview • Assembler • General • Components • Using Assembler • Assembler-related files • System Tasks • 4GL Installer • Locators

  31. Start with the Assembler • ISV uses Assembler for everything to do with packaging app for deployment • Comes with ProVision • ISV can invoke from Pro*Tools • ISV can invoke w/ RMB on project file (.wcp)

  32. Files to be Deployed • Application files to be deployed must be: • Collected together on development PC in Application Root Directory (ISV specifies it in General Tab) • AppRootDir must be accessible to Assembler--e.g. on same machine or reachable via File Open dialog • Relative pathnames for files are all relative to App Root Dir

  33. Files to be Deployed • Files under AppRootDir must be organized in same directory structure that they will have on end user machine (but application installation directory on end user machine will probably have a different name than root directory on ISV machine)

  34. Agenda • Overview • Assembler • General • Components • Using Assembler • Assembler-related files • System Tasks • 4GL Installer • Locators

  35. Separating Front End into Components • With IntelliStream, you can treat your entire application front end as one component, or split it into two or more components. • Three flavors of component • At Startup (recommended) • As-needed (optional) • Ask User at Startup (optional)

  36. Files to be Deployed • Types of files that can go into components: • .r files (Assembler doesn’t need .p files) • .pl files • OCX’s, DLL’s, icons, images • CAB file (CAB within CAB!) • any other type of file

  37. Three Flavors of Components • At startup: what you need to get going, plus utilities and shared code (e.g. ADM2) • As-needed: subsystems, should be as self-contained as possible • Ask: give user choice (now or later)

  38. “At Startup” Component • Everything needed to start the app (e.g. first screen and menus) • Utility code, common files • OCX’s and DLL’s that need to be registered (by System Tasks) • Files needed by 4GL Installer • ADM2 common code

  39. “As Needed” Component • Subsystem • Stuff not all users will run, or stuff that they won’t need right away (faster start without) • Tradeoff: faster start vs wait (for download) in the middle of running the app

  40. “Ask User at Startup” • WebClient will ask the user if s/he wants to download the component as part of the initial install • Allows end user to get all the installs out of the way at the beginning, for the subsystems s/he expects to use

  41. “Ask User at Startup” • Components user says “yes” to: WebClient downloads with “At Startup” component • Components user says “no” to: WebClient treats them as “As Needed” components

  42. Packaging Components • Assembler packages each component into a CAB file for downloading during app install: • Compression • Collection (whole component goes as one) • Digitally signed

  43. Packaging Components • CAB only for transport to user machine--WebClient deletes CAB file after expansion • After dust settles and CAB files deleted, app files on end user machine look same as: • They would look if installed without IntelliStream, and • They look on application development machine (except different root directory)

  44. Note on Components • For OCX’s used in 4GL, need .wrx file also--should be in same component as corresponding .r file • Can contain any type of file--but by default, WebClient only copies them down; any special handling (e.g. registering) requires install steps (System Tasks or 4GL Install)

  45. Agenda • Overview • Assembler • General • Components • Using Assembler • Assembler-related files • System Tasks • 4GL Installer • Locators

  46. Application Assembler • Generates three (sets of) CAB files: • Front end install downloads (CAB files) • Front end update downloads (CAB files) • Application Configuration File (in CAB file)

  47. Generating Install Files • ISV tells Assembler how many components and which files are in which components, plus some other info • ISV normally designates one component as “at startup”; all others (if any) are “as needed” or “ask user at startup”

  48. Generating Install Files • ISV hits Okay in “Generate” dialog • Assembler creates version-specific directory containing CAB files: • One CAB file containing the PROWCAPP file, and • One install CAB file for each component, containing all the files in that component

  49. Generating Install Files • ISV copies CAB files to Application Delivery server

  50. Generating Updates • ISV tells Assembler s/he wants to create a new version • Hits Okay in “Generate” dialog: • Creates a new directory for the version • Finds all app files that have changed • Collects changed files into one “diff” CAB file per component (only for components with changed files!)

More Related