Broswer vs. Desktop

Can someone please send me / refer me to a document summarizing the differences between Browser and Desktop?
What Should I consider when upgrading from Desktop to Browser?

Thank you :)

You can download the T24 Upgrade Browser Considerations.doc from below link
www.megaupload.com/?d=JTALFJL8

1. Review all the local developed source code attached as a routine to VERSION, ENQUIRY, DEAL.SLIP, etc. and remove the usage of the following JBASE/T24 functions:
- INPUT
- PRINT
- CRT
- TXTINP
- REM
- INPUT.BUFFER
- TXTINP and REM can be replaced with DISPLAY.MESSAGE and UPDATE.HEADER functions. The first three must be never used.
- INPUT.BUFFER can be replaced with EB.SET.NEXT.TASK or EB.SET.NEW.TASK. EB.SET.NEW.TASK do the same like EB.SET.NEXT.TASK but it will launch separate Browser Window where to execute what is passed

2. Review the functionality of each field in the VERSIONS. These fields which the Business Users requires to make action using a routine attached (validation or copying fields data somewhere else or other ) on passing the field have to be defined as Hot Fields or Hot Validate fields using the Attributes field in the VERSION template. All other validations or actions have to be moved from the routines attached as Validation routines to Input Routine. The last is required due to the fact that in R07.004 the sequence for execution of the validation routines when we commit a record using Browser is according to the Fields sequence in the Application Template and not according to the Fields sequence defined in the Version. In R08 this is amended and the sequence for execution of the Validation routines is according to the Fields sequence defined in the Version. Due to possible not correct results expected from the Business Users it’s better all Validations which are not defined as a Hot Field or Hot Validate Field to be moved in Input Routine.

3. It has to be noted that before to send a record from the Browser to the T24 Server the R.NEW global variable is empty. By sending the record it means the User to press Validate or Commit button or to trigger execution of Hot Field or Hot Validate Field. Upon review of how some current routines are designed and how they use the R.NEW variable values it is visible that such routines have to be defined as Hot Filed or Hot Validate Field routines otherwise a lot of routines have to be completely re-designed.

4. When we send a record from the Browser to the T24 Server the following updates happen:
- All fields (Including Hidden and No input) are sent from the browser to the server. Special note is made of fields that have changed or are in error
- All field updates run through OFS processing and placed in common memory ready for field updates.
- After RECORD.READ all fields that have not changed or are not in error are copied directly into R.NEW global variable.

5. Possible amendments in routines will be required in terms of showing the Enrichments for the Version Fields values:
- If your field is defined as a CHECKFILE in the Local Application then Browser will display the Enrichment.
- You can set your own enrichments inside a Validation Routine attached to the respective field and make the field a HOT.FIELD.
- All other Enrichments will NOT be displayed until the contract is validated or a HOT.VALIDATE is executed.

6. Possible amendments in routines will be required in terms of Overrides and Errors handling:
- Do NOT raise overrides during the Authorization stage.
- Use STORE.OVERRIDE to raise Overrides.
- Use STORE.END.ERROR to raise Errors.

7. Test of all existing ENQUIRIES in NBG Model Bank Release 1 how they are displaying and execution of possible amendments about:
- Remove any HEADER fields that are acting as column headers and update the values in FLD.LABEL field for the respective column in order to have correct columns heading.
- Need of amendment for how totals and sub-totals calculations are displayed in Browser in order to prevent displaying of empty enquiry columns and confusing content for the end user.

8. Test of all REPORT and DEAL.SLIPs printing and execution of potential amendments where necessary.

9. Possible modification of the default settings in the core applications: BROWSER.PARAMATERS, BROWSER.TOOLS, BROWSER.TOOLBAR in terms of:
- Whether for certain applications we will override the cache process and how F.OS.XML.CACHE is used.
- Whether the “Enter” key on the keyboard to be used as “Commit” key or not.
- Whether to have hot keys on the keyboard (e.g. Alt + C for Commit action) for certain buttons displayed on the Browser screen.
- Etc.

10. Possible modifications and records creation in applications EB.ATTRIBUTES and BROWSER.PREFERENCES in terms of:
- Screens and Enquiries coloring and appearing.
- User customization and personalization.

11. After the initial testing to find the potential issues, after all amendments in routines, versions, enquiries, etc., and after core Browser related applications configuration, User Acceptance Tests must be run by the Business Users to accept whether the Browser appearance and functionality covers their requirements.

12. If due to technical limitations (not enough Network Bandwidth, etc.) amendments have to be done to reduce the number of the Hot Fields per Version this will require re-design not only of some routines but and re-design of the Business Functionality presented currently with the Desktop. This has to be handled in addition to the pure technical migration and technical tasks for execution when we move from Browser to Desktop, which tasks are described in the previous points from 1 to 10.

Thank you msurii.

Exactly what I was looking for.

Appreciated.

Did you able to download the document from www.megaupload.com/?d=JTALFJL8 ?
If you have any difficulty let me know.

yes, I did.

Thanks again.

fine

According your explaination about (You can set your own enrichments inside a Validation Routine attached to the respective field and make the field a HOT.FIELD.)

Can you tell me how to do this ??

Best Regards,
Tjondro

Hi,

The link cannot access. can you share again?