Workflow for generating an IAC
By Mario Perez, Alexander Hildenbrand, Bernd Matzke, and Peter Zencke
Excerpted from SAP R/3 on the Internet by Mario Perez, Alexander Hildenbrand, Bernd Matzke, and Peter Zencke, published by Addison Wesley.
Generation of a Web application is an iterative process that passes through the development cycle described below. Practice has proved it almost impossible to generate Web objects for an R/3 application without changing the R/3 portion of the application.
Generating the R/3 transaction
An executable R/3 application serves as the starting point for a Web application. Because considerable differences exist between the Web and the SAP System, developers must adjust the R/3 application ot the characteristics of the Web. Details on this point are provided later. Executable does not mean that the application must fulfill the same ergonomic and visual requirements of a functional transaction that users would encounter when working with the SAPGUI. In this context, an executable R/3 application must simply function correctly and be operable considering some compromises in the R/3 System.
Developers can employ the normal development tools of the R/3 System without any restrictions to create and test the application.
Creating or changing the service description
A service description must exist on the file system on the ITS computer for each Web application. This file contains all the information that the ITS needs to call an SAP transaction. If you must create a service description, you must always create it with the Web-Studio. A normal text editor can handle any later changes to the description.
Creating or changing language resources
HTML templates should not contain any hard-coded language-dependent texts. When working with language-dependent graphics or texts not delivered directly from the R/3 System, developers must use language resources. Language resources maintain language dependent texts or language-dependent file names: the templates contain only placeholders. For language-independent templates, a language resource must exist for every login language so that the ITS can find the template. If the template doesn't contain any text elements, the resource file can remain empty.
If development does not involve any language-dependent templates, create at least one language resource for the language used in developing and testing the application.
Creating or changing templates
An HTML tempalte must exist for every screen of the R/3 transaction. The template must contain various HTMLBusiness statements that create references to the corresponding screen fields. The Web-Studio can generate such a template from a screen description. The Studio automatically generates the required placeholders and control statements. In almoste very case, an automatically generated page requires manual editing. Any screen changes will also require reworking of the templates. If the screen has changed, developers can enter the changes into the template manually or generate a new page autmoatcially from the new screen description. In the latter case, the new template would not contain any edits made previously. We recommend making backup copies of previously generated templates before creating any new ones.
Editing a template does more than improve the visual appearance of Web pages. Special programming techniques or frame applications require HTMLBusiness statements to guarantee the interplay of HTML pages and SAP screen. Developers must insert such instructions manually.
Testing the application
After creating or changing objects, you must test the application. The test must run with the Web application to check the interplay of all components. A range of possible errors exists outside of the R/3 System. Any of these errors may well cause an application that works correctly within the R/3 System to malfunction on the Web. Tools, among them the ITS debugger, can help locate the error.
To read more about this and other SAP R/3 Internet issues, click to find out about SAP R/3 on the Internet.