Application Design

RMD (Retail Market Development)(TBG to TESS migration)

Application Design DocumentInception/Elaboration Phase

Version History#DateVersionDescriptionAuthor

14/7/20151.0 Initial versionNavin George

2

3

4

Approvals#DateVersionApproverComments

Table of Contents1.Application Design Goals and Constraints31.1Note31.2Goals31.3Constraints31.4Work in Progress items32.Use-Case Realizations32.1Idle Session Timeout42.2Implement means to link application session to TESS session82.3Implement Logout Warning102.4Consume attribute and application role information from TESS112.5Map TMS Corporate Users, Domestic Dealer Users and PD Corporate users and SET Dealer Users User ID and roles are migrated from TBG to TESS123.Application Architecture153.1Overview154.Deployment Approach154.1Deployment Model154.2Rollback Strategy164.3Builds164.4Proposed TESS URLS165.Unit Testing and Integration Testing175.1Unit Testing175.2Development Integration Testing175.3Regression Testing17Appendix A List of Technologies17

1. Application Design Goals and Constraints1.1 NoteWe are not using the App framework code as is since we are COTS application and also use a WebSphere server.1.2 GoalsThe primary goal of this project is to maintain all the functionalities of the existing RMD applications after the migration from TBG to TESS platform which will include the following: To provide a standards-based, scalable, reusable, flexible, and extensible environment To provide a simplified, consistent environment to maintain or manage the application To allow maximum leverage / reuse of existing application & tool investments To support on-going changes in business strategy To be designed to address continued improvement & changes to customer needs and other initiatives Compliance, to the greatest extent possible, with all relevant Toyota reference architectures and standards Minimize the infrastructure and software maintenance at the dealership

1.3 Constraints The solution architecture should adhere to guiding principles of the Toyota Reference Architecture (TRA) Reporting Application has been developed in Weblogic Portal Framework (Weblogic Portals were developed on top of Struts Framework) and the Web Screen application has been developed on the Spring Framework. Hence an extensive Regression & Performance Testing is needed to ensure there is no impact to existing Application functionalities. The application architecture should adhere to industry standard best practices through the use of design patterns and frameworks The application architecture must support the evolution of the application into functional components implementing well-architected services

1.4 Work in Progress itemsN/A

2. Use-Case Realizations

Post TESS the system should facilitate the existing RMD Functionalities AS-IS without any impact to the existing system.The following are the use cases for TESS Migration in RMD Session Management (Idle Session Timeout) Implement means to link application session to TESS session Implement Logout Warning Consume attribute and application role information from TESS Map TMS Corporate Users, Domestic Dealer Users and PD Dealer Users User ID and roles are migrated from TBG to TESS

2.1 Idle Session TimeoutIdle Session Timeout functionality will warn the user, if the application remains inactive for fixed time duration. In that case, a pop-up will appear on the screen, giving options to the user to extend the session. If the user clicks on OK, session will be extended else if the user clicks on Cancel the pop up will be closed.

Idle session timeout will be implemented with the help of App framework. Various parameters can be configured as part of the framework in the property file. Ex: heartbeat URL, polling frequency, idle session timeout warning message display duration, idle session timeout warning message and session expiry message will be configured through the framework property file.

Solution Approach:

1. The JavaScript file (IdleSessionTimeout.js) will be leveraged by the application (Include) to invoke validateIdleSessionTimeout() method. The components of IdleSessionTimeout.js will leverage plain vanilla JavaScript. It will do the following.

2. IdleSessionTimeout.js will be included in the header.inc (Reporting) and menu.jsp (Web). So that, this script will be executed on any navigations through pages in the application.

3. TESS session expiration time will be read once from the Http response header (TS_SESSIONEXPIRATION). If the value does not exist, validateIdleSessionTimeout() would invoke an AJAX call to call Heartbeat servlet which retrieves response headers and read TESS expiration time, lastAccessedTime. Once the value is available, it will be set in SESSION scope to avoid making additional calls.

4. A timer will be created using JavaScript Timer through triggerIdleTimer(). This will run independently on the client side. This will poll every X seconds (The value to configure on day one is 30 seconds) to check on idle session timeout eligibility. This will leverage the client clock.

5. A Filter will intercept all http request (both synchronous/Asynchronous calls) and if the url pattern does not match /appFramework/heartbeat then session variable will be updated with the sessions last accessed time.

6. The idle session timeout duration (The value to configure on day one is 5 hours), idle session timeout warning message display duration (The value to configure on day one is 15 minutes) and the current time will be leveraged by the timer code to display the warning message by warning message display duration. The below mentioned expiration check will be performed by validateSessionExpiry() method. If (current time lastAccessedTime >= idle session timeout idle session timeout warning message display duration), then the eligibility to display the warning message is met.

7. Once the eligibility criteria is met for idle session timeout warning message, call showWarningPopup() (1 minute in advance of idle session timeout duration - idle session timeout warning message display duration)

A modal popup will be created on demand by constructWarningpopup() script method

8. A new timer will be created to close the warning popup automatically after idle session timeout warning message display duration (It is to be configured as 15 minutes on day one)

9. If the user accepts to continue on the session by clicking on the Ok button, then it will make a heartbeat call through AJAX to activate the session.

A heartbeat URL provided by the application will be leveraged for this purpose. The standard heartbeat code mapped to a static context URI like /appFramework/heartbeat will be enabled.

10. If the user performs Cancel action, validateSessionExpiry() function call will display session expiry message to the user and the pop up will be closed.

Properties to be configured

Property NameDescription

IDLE_SESSION_TIMEOUTThis is the total duration for which any session can be idle, beyond which logout will be done automatically. (value in minutes)

IDLE_SESSION_POLL_FREQUENCYThis is the interval between which, it is checked whether the idle session timeout has been reached. (value in milliseconds)

IDLE_SESSION_TIMEOUT_MSG_DISPLAY_DURATIONThis is the amount of time before the ending of idle session timeout; the idle session timeout warning message will be displayed. (value in minutes)

APPLICATION_NAMEThis denoted the Application name (For standard heartbeat URI construct)

IDLE_SESSION_TIMEOUT_WARNING_MSGIdle session time out warning popup message. Defaults Your session is about to be timed out. Click OK to continue your current session

HEART_BEAT_URLheartbeat URL provided by the application

TESS_SESSION_EXPIRY_MSGTESS session expiry message. Defaults Your session has expired as maximum allowed duration has crossed

Modification History

Sl. No.File NameMethod NameChange Description (Added / Modified)Path

1RMDReportingConfig.properties(Reporting)Modified/RMDReporting/config (Reporting)

2sessionTimeout.properties(web)Added/drorWAR/src/main/resources (web)

Process flow

Start

User Logs in

System remains inactive and reaches Advance Notice Period

Do you want to continue the session?

Yes No

Check whether session is expired or not?

No Action

Session is expired

No Yes

No Action

Redirected to logout pagePopup is closedSession becomes active and timer is reset

End

2.2 Implement means to link application session to TESS session

Session misuse avoidance is a solution that prevents session misuse in a shared desktop or multiple applications that are running in single sign-on. In this case, RMD will implement custom solution to link application session to TESS security session. When user log off and/or close their browser, their session is terminated safely. The main objective of this implementation is to prevent session misuse or hijacking.

Solution approach:

1. RMDSecureDispatcherServlet(Reporting) and SecurityFilter(web) will intercept all incoming requests.

2. The user id information will be extracted from TESS header attribute OAM_REMOTE_USER. This will be performed using request.getHeader(), where request is an instance of HttpServletRequest.

3. Previous user-id will be tracked as a session attribute.

4. If the previous user-id is not set, then the same will be set as the current user-id (Value of TESS header attribute OAM_REMOTE_USER)

5. If the previous user-id exists as the session attribute value, then the same will be compared against the current user-id (Value of TESS header attribute OAM_REMOTE_USER). If they are identical, then the access will be allowed. If not, the session will be invalidated.

Modification History

Sl. No.File NameMethod NameChange Description (Added / Modified)Path

1RMDSecureDispatcherServlet.java (Reporting)doService()Modifiedcom.tms.rmd.security

2SecurityFilter.java (web)initializeUserRole()Modifiedcom.tms.dror.web

Process flow

Userid is extracting from the header.Check whether Userid is exists in the session or not?StartUserid is set in the sessionCheck whether Extracted Userid and userid in the session are equal or not?Application access is allowed.Session is invalidated and Redirected to login page.EndNoYesEqualNot Equal

2.3 Implement Logout Warning

The functionality for the logout warning message needs to be provided as part of TESS migration. When user logs out of RMD application, a warning message gets posted on the screen and on confirmation from the warning message, the sessions on RMD application will be killed and the logout URL will be called.

Solution Approach:

1. When user clicks on Logout hyperlink, the script at header.inc/menu.jsp would display a warning message model pop up implemented through JavaScript.2. If user clicks on Ok button, it would call logout.jsp. Here session is validated, all cookies are cleared and application specific logout url is invoked.

EnvironmentLogout URL

Shared Developmenthttps://ssologin-s01.dev.toyota.com/tesslogin/logout.jsp?end_url=

Shared Development Futurehttps://ssologin-f01.dev.toyota.com/tesslogin/logout.jsp?end_url=

Shared QAhttps://ssologin-s01.qa.toyota.com/tesslogin/logout.jsp?end_url=

Shared QA Futurehttps://ssologin-s02.qa.toyota.com/tesslogin/logout.jsp?end_url=

Stagehttps://ssologin-stg01.qa.toyota.com/tesslogin/logout.jsp?end_url=

Productionhttps://ssologin.toyota.com/tesslogin/logout.jsp?end_url=

Modification HistorySl. No.File NameMethod NameChange Description (Added / Modified)Path

1Header.inc (Reporting)Modified /RMDReporting/WebContent/WEB-INF/jsps/common/

2logout.jsp (Reporting)Modified/RMDReporting/WebContent/WEB-INF/jsps/common/

3logout.jsp (web)Added /drorWAR/src/main/webapp/jsp/(web)

Process flow

2.4 Consume attribute and application role information from TESS

The following are the attributes and the access management patterns required from TESS when the user is logging in through TESS into RMD:

#Attribute NameLDAP ServerTESS HTTP Header

1Display NameX

2User ID (Login ID) X

3Session Expiration attributes (Creation, Expiration, Count)X

4Roles/Groups (specific to application) for reporting applicationX

5Roles/Groups (specific to application) for web(DROR) applicationX

6Dealer NumberX

Solution Approach:

Consume attributes from TESS HTTP Header (Both reporting and web application)

Display Name, User ID, Dealer Number, Roles/Groups (Web) and Session Expiration attributes will be extracted from TESS header attribute. This will be performed by using request.getHeader(), where request is an instance of HttpServletRequest.

Consume Roles/Groups from LDAP Server (Reporting application)

Here, we can use existing JNDI LDAP code with little modifications in the LDAP properties.

Modification History

Sl. No.File NameMethod NameChange Description (Added / Modified)Path

1RMDReportingconfig.properties (Reporting)Modified /RMDReporting/config/

2JndiLdapUserBeanCreator.java (Reporting)Modifiedcom.tms.rmd.security

2.5 Map TMS Corporate Users, Domestic Dealer Users and PD Corporate users and SET Dealer Users User ID and roles are migrated from TBG to TESS

TMS Corporate Users:All the agreed roles for TMS Corporate Users should be created in TESS. Validate all the TMS Corporate users and their respective new roles are migrated from TBG to TESS. All the respective users should be able to login into application

One Dealer Daily (1DD):Mapping of User ID and roles for Toyota & Lexus Domestic Dealer Users have to be taken care by DD team.

PD Corporate users:1) Whenever PD admin team creating new PD UID for a user, at the same time TESS should create corresponding TMS UID.2) Internal mapping between PD UID and TMS UID maintained by TESS.3) RMD Business team can now open PD Corporate user account to assign and revoke application roles directly.4) Now PD Corporate user can login in RMD web and reporting portals using PD UID. The TESS will validate the login PD UID with corresponding TMS UID and credentials internally. Solution Approach:

Reporting application: User ID will be extracted from TESS Header Based on User ID, role codes will be taken from TESS LDAP Server Currently in application all the TBG role names are configured as constants in UserBean.java, It will be modified with respective Tess role names. Application will be utilized existing code flow for retrieving role information based on role codes. All the role names will be modified in navigation-context.xml also Based on role name and navigation-context.xml, application will be decided the required user components and menus for user interface.Web application:TMS Corporate Users User ID will be extracted from TESS Header. Based on User ID, role codes will be taken from TESS AM Web Service. In web application all the role names are saved in DROR.USR_ROLE master table, it will be modified with respective Tess role names. Application will be utilized existing code flow for retrieving role information from DROR.USR_ROLE, DROR.USR_ROLE_ACCS_GRP and DROR.ACCS_GRP tables.One Dealer Daily (1DD) and PD Corporate User Obtaining user id and user roles remain same as TMS Corporate Users. The selected dealer code will be getting through HTTP header (Dealer Number) , the corresponding screen will be made available to the user.

Modification History

Sl. No.File NameMethod NameChange Description (Added / Modified)Path

1Navigation-context.xml(Reporting)Modifiedsrc/com/tms/rmd/navmenu

2UserBean.java (Reporting)Modified com.tms.rmd.security

List of TESS Roles

#Role DescriptionTESS Role names - AS-IS ApproachTESS Proposed TESS Role names - TO-BE Approach

1Dealer User Financial StatementDealerUserFSRMD_Dealer_Financial_Statement_User

2RMD Application EnrolledEnrolledRMD_Enrolled

3TMS Sales NationalAllDealersRMD_All_Dealers

4TMS Lexus CompanyAllLexusRMD_All_Lexus

5TMS Toyota CompanyAllToyotaRMD_All_Toyota

6Boston RegionBostonRegionEnterprise_TMS_Region_Boston

7Business ManagementBusinessManagementRMD_Business_Management

8Central Atlantic ToyotaCentralAtlanticRegionEnterprise_TMS_Region_Central_Atlantic

9Chicago RegionChicagoRegionEnterprise_TMS_Region_Chicago

10Cincinnati RegionCincinnatiRegionEnterprise_TMS_Region_Cincinnati

11Denver RegionDenverRegionEnterprise_TMS_Region_Denver

12Gulf States Toyota UserGSTPDCorpUserEnterprise_GST_Distributor_Gulf_States_Toyota

13Kansas City RegionKansasCityRegionEnterprise_TMS_Region_Kansas_City

14Lexus Central RegionLexusCentralAreaEnterprise_TMS_Area_Lexus_Central

15Lexus Eastern RegionLexusEasternAreaEnterprise_TMS_Area_Lexus_Eastern

16Lexus Southern RegionLexusSouthernAreaEnterprise_TMS_Area_Lexus_Southern

17Lexus Western RegionLexusWesternAreaEnterprise_TMS_Area_Lexus_Western

18Los Angeles RegionLosAngelesRegionEnterprise_TMS_Region_Los_Angeles

18Market RepresentationMarketRepRMD_Market_Rep

19New York RegionNewYorkRegionEnterprise_TMS_Region_New_York

20Portland RegionPortlandRegionEnterprise_TMS_Region_Portland

21RMD Report Admin UserRMDReportAdminRMD_Report_Admin

22San Francisco RegionSanFranciscoRegionEnterprise_TMS_Region_San_Francisco

23Southeast Toyota UserSETPDCorpUserEnterprise_SET_Distributor_Southeast_Toyota

24Web App UserWebAppUserRMD_Web_App_User

25TFS UserTFSUserRMD_TFS_User

3. Application Architecture3.1 OverviewRMD TESS migration being a Migration Process, It will migrate existing RMD application from TBG (Toyota Business Gateway) to TESS (Toyota Enterprise solution services). It follows the existing RMD architecture and frameworks. Refer TIS-TAS-Solution_Architecture.doc for detailed architecture. 4. Deployment Approach4.1 Deployment ModelAs depicted in the below diagram, two flows have been defined. Regular releases in RMD will utilize the DEV, QA & PROD environment for Development, Validation and Prod Roll Out. TESS Changes in RMD will utilize the TEST, QA2 & PROD2 environment for Development, Validation and Prod Roll Out.

A new branch will be created in all the applications based on the Production Branch. Any code changes to TESS will be done in this branch marked for TESS. Before moving TESS functionalities to UAT, the Code which is present in the Production Branch at that time will be merged to the TESS branch. A round of regression testing will be done before delivering the same to UAT.

4.2 Rollback StrategyPrevious production build version will be deployed by the Implementation groups (Mainframe-OS & BI Server teams).

4.3 BuildsBuild process will be similar to existing system build process.

4.4 Proposed TESS URLS

List of URLs for RMD Reporting:EnvironmentTBG URLTESS URL

Devhttp://rmdreports.dev.toyota.comhttp://rmdreports.dev.toyota.com

Testhttp://rmdreports.test.toyota.comhttp://rmdreports.test.toyota.com

QAhttp://rmdreports.qa.toyota.comhttp://rmdreports.qa.toyota.com

PRODUCTIONhttp://rmdreports.toyota.comhttp://rmdreports.toyota.com

List of URLs for RMD Web:

EnvironmentTBG URLTESS URL

Devhttp://rmd.dev.toyota.comhttp://rmd.dev.toyota.com

Testhttp://rmd.test.toyota.comhttp://rmd.test.toyota.com

QAhttp://rmd.qa.toyota.comhttp://rmd.qa.toyota.com

PRODUCTIONhttp://rmd.toyota.comhttp://rmd.toyota.com

List of OADD URLs for RMD:

EnvironmentTBG URLTESS URL

DevNANA

TestNANA

QAhttps://oaddrmdreports.qa.lexus.comhttps://oaddrmdreports.qa.toyota.comhttps://oaddrmd.qa.toyota.comhttps://oaddrmd.qa.lexus.comhttps://oaddrmdreports.qa.lexus.comhttps://oaddrmdreports.qa.toyota.comhttps://oaddrmd.qa.toyota.comhttps://oaddrmd.qa.lexus.com

PRODUCTIONhttps://oaddrmdreports.lexus.comhttps://oaddrmdreports.toyota.comhttps://oaddrmd.toyota.comhttps://oaddrmd.lexus.comhttps://oaddrmdreports.lexus.comhttps://oaddrmdreports.toyota.comhttps://oaddrmd.toyota.comhttps://oaddrmd.lexus.com

5. Unit Testing and Integration TestingThis section describes the testing strategy by development before QA and UAT is conducted.

5.1 Unit TestingUnit testing will be performed by the developers who make the changes on the modules closely related to the changed functionalities.

5.2 Development Integration Testing

Test Scenario #PurposeTest Condition or Functionality To Be TestedExpected Results

1.Application should work properly after TESS Migration.All the functionalities along with added should be validated after migration.No impact to the existing system.

5.3 Regression TestingRegression Testing will be done manually, It needs to be suited the below mentioned requirements for TESS. Modification of URLs to suit new TESS URLs. Appendix A List of TechnologiesTechnologiesVersionLicense TypeVendorPurposeURL

EJB2.0Open SourceOraclePersistencehttp://www.oracle.com/technetwork/java/javaee/ejb/index.html

Weblogic9.2CommercialBEA SystemsJ2EE Containerhttp://docs.oracle.com/cd/E13222_01/wls/docs92/

Java1.5(Reporting)1.6(Web)Open SourceOracleJava Development Kithttp://www.oracle.com/technetwork/java/index.html

Hibernate3.0Open SourceRed HatPersistencehttp://hibernate.org/

Spring2.0.5Open SourcePivotal SoftwareApplication frameworkhttp://projects.spring.io/spring-framework/

Websphere8.5CommercialIbmJ2EE Containerhttp://www-01.ibm.com/software/webservers/appserv/was/library/

Struts2.0Open SourceApache Software FoundationWeb frameworkhttp://struts.apache.org/

Application Design.doc Protected Page 3 of 18