You can create a JSP element that uses a Web application archive (WAR) file that is on the application server.
From the Mobile Development perspective, select File|New|Mobile Application.
Alternatively, right-click the Mobile Applications folder, and select Create New Mobile Application With|JSP Element.
When the New Mobile Application wizard appears, select Launch Element Wizard, select JSP from the drop-down list and click Finish.
In the JSP Element dialog, select Use Web Application.
In WAR File, enter the path to the Web application.
Enter the Initial JSP – the initial JSP page to display.
Complete these options:
Web App Qualified URLs – enter a URL with parameters to call a Web application from the JSP mobile application. See "Using a remote URL."
Enable Grid Rules – establish grid rules for your JSP element. See Rules and Record Layout for more information.
Single Sign-On Required – select if single sign-on is required. When you select this option, three more options become available:
JSP Include – use the javax.servlet.RequestDispatcher.include(...) method to enable the target JSP to retrieve the JSP's contents. This method returns the target JSP's output to the portal and allows you to manipulate, filter, and integrate that output with other elements in a mobile application with multiple elements—an aggregate mobile application. Aggregate mobile applications use either an <IFRAME> or <DIV> tag style.
The target JSP gets a contextPath in the ServletRequest object that matches the application name under which the JSP is installed.
JSPs using the .include() method have a <BASE HREF="targetJSP path"> element inserted into the HTML <HEAD> element. This ensures that relative HREFs or IMG links generated from that JSP are loaded correctly.
JSP Forward – use the javax.servlet.RequestDispatcher.forward(...) method to enable the target JSP to retrieve the JSP's contents. This method does not return the target JSP's output back to the portal.
This mobile application style must run in an <IFRAME> tag and cannot be included in an aggregate mobile application (with multiple elements). The forward method ensures that the target JSP receives the contextPath with which it was installed. There is no opportunity for the portal to insert the <BASE HREF=...> element into the returned HTML, so if the <BASE HREF=...> information is not provided by the mobile application, relative HREFs or IMG links may not work.
302 Redirect – this option generates a HTTP Status 302 redirect back to the browser. When the browser receives a 302 redirect status, it executes a get method to the URL contained in that 302 message. This mobile application style must run in an <IFRAME> tag, otherwise the mobile application overlays the entire screen.
One benefit of this mobile application style, is that the declarative J2EE security constraints that are part of the target Web application are enforced by the container. The J2EE standard does not require the container to apply declarative security constraints for RequestDispatcher include or forward.
Web applications in J2EE containers can have security descriptors that are mentioned in a web.xml file. This section of the XML puts a constraint on all the resources of the Web application. Access is granted only to users in the manager role. Users who try to access the Web application from the client program must be authenticated. If the type of authentication required is basic authentication, the user is prompted for a user name and password.
If the Web application is added as a mobile application to a page, users need not reauthenticate with the application. The mobile application uses container authentication to authenticate users when they log in to the mobile application. The same session context that authenticates the user with the Web application is used to authenticate the user with a mobile application. If the user roles are the same across the Web application, the user is authenticated into the Web application and the contents display in the Web application.
See the Enterprise Security Administration Guide for details.
Input Parameters – enter the input parameter names as defined by the JSP code.
You must use a name-value pattern like this:
name1=value1&name2=value2&name3=value3
The name must be exactly the same as your JSP code's input parameter. For example, if the JSP page's code is:
EPLogin:<input type ="text" name="epuser"> EPPswd:<input type="password" name="eppassword"> HostName:<input type="text" name="hostname"> AssetDN:<input type ="text" name="asset"> PAI URL:<input type="text" name="paiURL">
The input parameters must then be:
epuser=tester&eppassword=test123&hostname=drillbit2k&asset=a1=pubs, dc=sybase,dc=com&paiURL=jdbc:sybase:Tds:sapphire:5000/pubs2
When you are satisfied with your entries, click Next. Preview the JSP element.
Click Finish.
JSP mobile application single-sign-on check box
When you create a JSP mobile application from a WAR file, there is a check box labeled Single Sign On (SSO). If you do not select this option, the implications are:
The JSP mobile application is invoked without any credentials passed to it.
If the JSP mobile application has the directive <% page session="true" %> in the JSP page, a new HTTP session is created whenever the JSP mobile application is invoked.
A cookie is sent back to the portal, but the cookie is not remembered. Therefore, any state stored within the HTTP session is lost.
Repeated use of the JSP mobile application can create a severe memory drain to the system.
Send your feedback on this help topic to Sybase Tech Pubs: pubs@sybase.com