RMD (Retail Market Development)

(TBG to TESS migration)

Application Design Document
Inception/Elaboration Phase

Version History
#
1
2
3
4

Date
4/7/2015

Versio
n
1.0

Description
Initial version

Author
Navin George

Approvals
#

274378801

Date

Versi
on

Approver

Protected

Comments

Page 1 of 19

Table of Contents
1.

Application Design Goals and Constraints

1.1
Note
1.2
Goals
1.3
Constraints
1.4
Work in Progress items

3
3
3
3
3

2.

Use-Case Realizations
3
2.1
Idle Session Timeout
4
2.2
Implement means to link application session to TESS session
8
2.3
Implement Logout Warning
10
2.4
Consume attribute and application role information from TESS
11
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
12

3.

Application Architecture
3.1
Overview

15
15

4.

Deployment Approach
4.1
Deployment Model
4.2
Rollback Strategy
4.3
Builds
4.4
Proposed TESS URLS

15
15
16
16
16

5.

Unit Testing and Integration Testing

5.1
Unit Testing
5.2
Development Integration Testing
5.3
Regression Testing

17
17
17
17

Appendix A List of Technologies

274378801

17

Protected

Page 2 of 19

1. Application Design Goals and Constraints

1.1

Note

We are not using the App framework code as is since we are COTS application and also
use a WebSphere server.

1.2

1.3

1.4

Goals
The 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
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
Work in Progress items
N/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
274378801

Protected

Page 3 of 19

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 Timeout

Idle 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

will run independently on the
value to configure on day one
eligibility. This will leverage the

JavaScript Timer through triggerIdleTimer(). This

client side. This will poll every X seconds (The
is 30 seconds) to check on idle session timeout
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.

274378801

Protected

Page 4 of 19

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 Name

Description

IDLE_SESSION_TIMEOUT

This is the total duration for which any session can be

idle, beyond which logout will be done automatically.
(value in minutes)

IDLE_SESSION_POLL_FREQUENC
Y

This is the interval between which, it is checked whether

the idle session timeout has been reached. (value in
milliseconds)
This is the amount of time before the ending of idle
session timeout; the idle session timeout warning
message will be displayed. (value in minutes)

IDLE_SESSION_TIMEOUT_MSG_
DISPLAY_DURATION
274378801

Protected

Page 5 of 19

APPLICATION_NAME
IDLE_SESSION_TIMEOUT_WARNI
NG_MSG
HEART_BEAT_URL
TESS_SESSION_EXPIRY_MSG

This denoted the Application name (For standard

heartbeat URI construct)
Idle session time out warning popup message. Defaults
Your session is about to be timed out. Click OK to
continue your current session
heartbeat URL provided by the application
TESS session expiry message. Defaults Your session has
expired as maximum allowed duration has crossed

Modification History
Sl
.
N
o.
1
2

274378801

File Name

Method Name

RMDReportingCon
fig.properties(Rep
orting)
sessionTimeout.pr
operties(web)

Change
Descriptio
n (Added /
Modified)
Modified
Added

Protected

Path
/RMDReporting/config
(Reporting)
/drorWAR/src/main/resources
(web)

Page 6 of 19

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

274378801

No Action

Yes

Session is
expired

Protected

Page 7 of 19

No Action
Session becomes
active and timer
is reset

Popup is closed

Redirected to
logout page

End

2.2Implement 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
.
N
274378801

File Name

Method Name

Change
Description
(Added /

Protected

Path

Page 8 of 19

o.

1
2

Modified)
RMDSecureDis
patcherServlet

doService()

Modified

com.tms.rmd.security

SecurityFilter.j

initializeUserRole()

Modified

com.tms.dror.web

.java
(Reporting)
ava (web)

Process flow

274378801

Protected

Page 9 of 19

Start

Userid is extracting from the header.

Yes

No

Check whether Userid is exists in the session or not?

Userid is set in the session

Not Equal

Equal

Check whether Extracted Userid and userid in the session are equal or not?

Application access is allowed.

Session is invalidated and Redirected to login page.

End

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
274378801

Protected

Page 10 of 19

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.

Environment
Shared
Development
Shared
Development
Future
Shared QA
Shared QA Future
Stage
Production

Logout URL
https://ssologin-s01.dev.toyota.com/tesslogin/logout.jsp?
end_url=<APP_URL>
https://ssologin-f01.dev.toyota.com/tesslogin/logout.jsp?
end_url=<APP_URL>
https://ssologin-s01.qa.toyota.com/tesslogin/logout.jsp?
end_url=<APP_URL>
https://ssologin-s02.qa.toyota.com/tesslogin/logout.jsp?
end_url=<APP_URL>
https://ssologin-stg01.qa.toyota.com/tesslogin/logout.jsp?
end_url=<APP_URL>
https://ssologin.toyota.com/tesslogin/logout.jsp?
end_url=<APP_URL>

Modification History
Sl.
No
.

File Name

Header.inc
1 (Reporting)
logout.jsp
2 (Reporting)
3 logout.jsp (web)

274378801

Method
Name

Change
Descript
ion
(Added /
Modifie
d)
Modified
Modified
Added

Protected

Path

/RMDReporting/WebContent/WEBINF/jsps/common/
/RMDReporting/WebContent/WEBINF/jsps/common/
/drorWAR/src/main/webapp/jsp/
(web)

Page 11 of 19

Process flow

2.4Consume 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:

#
1
2
3
4
5
6

274378801

Attribute Name

LDAP Server

TESS HTTP Header

Display Name
User ID (Login ID)
Session Expiration
attributes (Creation,
Expiration, Count)
Roles/Groups (specific
to application) for
reporting application
Roles/Groups (specific
to application) for
web(DROR) application
Dealer Number

X
X

Protected

Page 12 of 19

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.
N
o.

Method
Name

File Name

RMDReportingconfig.prop
1 erties (Reporting)
JndiLdapUserBeanCreator
2 .java (Reporting)

Change
Descript
ion
(Added
/
Modifie
d)
Modified
Modified

Path

/RMDReporting/config/
com.tms.rmd.security

2.5Map 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.

274378801

Protected

Page 13 of 19

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.

274378801

File Name

Method
Name

Protected

Change
Descript
ion
(Added
/
Modifie
d)

Path

Page 14 of 19

Navigation-

Modified

1 context.xml(Reporting)
UserBean.java

Modified

2 (Reporting)

src/com/tms/rmd/navmenu
com.tms.rmd.security

List of TESS Roles

#
1
2
3
4
5
6
7

12

Business Management
Central
Atlantic
Toyota
Chicago Region
Cincinnati Region
Denver Region
Gulf States Toyota
User

13
14

Kansas City Region

Lexus Central Region

15
16

Lexus Eastern Region

Lexus
Southern
Region

17

Lexus Western Region

18

21

Los Angeles Region

Market
Representation
New York Region
Portland Region
RMD Report Admin
User

22

San Francisco Region

8
9
10
11

18
19
20

274378801

Role Description
Dealer User Financial
Statement
RMD
Application
Enrolled
TMS Sales National
TMS Lexus Company
TMS Toyota Company
Boston Region

TESS Role
names - AS-IS
Approach

TESS Proposed TESS Role names TO-BE Approach

DealerUserFS

RMD_Dealer_Financial_Statement_User

Enrolled
AllDealers
AllLexus
AllToyota
BostonRegion
BusinessManage
ment
CentralAtlanticRe
gion
ChicagoRegion
CincinnatiRegion
DenverRegion

RMD_Enrolled
RMD_All_Dealers
RMD_All_Lexus
RMD_All_Toyota
Enterprise_TMS_Region_Boston

GSTPDCorpUser
KansasCityRegio
n
LexusCentralArea
LexusEasternAre
a
LexusSouthernAr
ea
LexusWesternAre
a
LosAngelesRegio
n

RMD_Business_Management
Enterprise_TMS_Region_Central_Atlantic
Enterprise_TMS_Region_Chicago
Enterprise_TMS_Region_Cincinnati
Enterprise_TMS_Region_Denver
Enterprise_GST_Distributor_Gulf_States_To
yota
Enterprise_TMS_Region_Kansas_City
Enterprise_TMS_Area_Lexus_Central
Enterprise_TMS_Area_Lexus_Eastern
Enterprise_TMS_Area_Lexus_Southern
Enterprise_TMS_Area_Lexus_Western
Enterprise_TMS_Region_Los_Angeles

MarketRep
NewYorkRegion
PortlandRegion

RMD_Market_Rep
Enterprise_TMS_Region_New_York
Enterprise_TMS_Region_Portland

RMDReportAdmin
SanFranciscoRegi
on

RMD_Report_Admin

Protected

Enterprise_TMS_Region_San_Francisco
Page 15 of 19

23
24
25

Southeast Toyota User

Web App User
TFS User

SETPDCorpUser
WebAppUser
TFSUser

Enterprise_SET_Distributor_Southeast_Toy
ota
RMD_Web_App_User
RMD_TFS_User

3. Application Architecture
3.1

Overview
RMD 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-TASSolution_Architecture.doc for detailed architecture.

4. Deployment Approach
4.1

Deployment Model

As 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.

274378801

Protected

Page 16 of 19

4.2

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.

Rollback Strategy

Previous production build version will be deployed by the Implementation groups

(Mainframe-OS & BI Server teams).
4.3

Builds

Build process will be similar to existing system build process.

4.4

Proposed TESS URLS

List of URLs for RMD Reporting:

Environment
Dev
Test
QA
274378801
PRODUCTION

TBG URL
http://rmdreports.dev.toyota.com
http://rmdreports.test.toyota.com
http://rmdreports.qa.toyota.com
Protected
http://rmdreports.toyota.com

TESS URL
http://rmdreports.dev.toyota.com
http://rmdreports.test.toyota.com
http://rmdreports.qa.toyota.com
Page 17 of 19
http://rmdreports.toyota.com

List of URLs for RMD Web:

Environment
Dev
Test
QA
PRODUCTION

TBG URL
http://rmd.dev.toyota.com
http://rmd.test.toyota.com
http://rmd.qa.toyota.com
http://rmd.toyota.com

TESS URL
http://rmd.dev.toyota.com
http://rmd.test.toyota.com
http://rmd.qa.toyota.com
http://rmd.toyota.com

List of OADD URLs for RMD:

Environment
Dev
Test
QA

TBG URL
NA
NA
https://oaddrmdreports.qa.lexus.com
https://oaddrmdreports.qa.toyota.co
m
https://oaddrmd.qa.toyota.com
https://oaddrmd.qa.lexus.com

PRODUCTION

https://oaddrmdreports.lexus.com
https://oaddrmdreports.toyota.com
https://oaddrmd.toyota.com
https://oaddrmd.lexus.com

TESS URL
NA
NA
https://oaddrmdreports.qa.lexus.
com
https://oaddrmdreports.qa.toyota
.com
https://oaddrmd.qa.toyota.com
https://oaddrmd.qa.lexus.com
https://oaddrmdreports.lexus.co
m
https://oaddrmdreports.toyota.co
m
https://oaddrmd.toyota.com
https://oaddrmd.lexus.com

5. Unit Testing and Integration Testing

This section describes the testing strategy by development before QA and UAT is
conducted.
5.1
Unit Testing
Unit 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

Purpose

Test

Scenario #
1.

274378801

Condition

or

Expected Results

Functionality To Be
Application should
work properly after
TESS Migration.

Tested
All the functionalities
along
with
added
should be validated

Protected

No impact to the existing

system.

Page 18 of 19

after migration.
5.3
Regression Testing
Regression 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 Technologies
Technolo

Version

gies
EJB

2.0

Type
Open

9.2

Source
Commerci

1.5(Rep

al
Open

orting)

Source

Weblogic
Java

License

Vendor

Purpose

URL

Oracle

Persistenc

http://www.oracle.com/technetwork/java/
javaee/ejb/index.html

BEA Systems

e
J2EE

s/docs92/

Oracle

Container
Java
Developm

twork/java/index.html

1.6(Web
Hibernate
Spring

Websphere

http://www.oracle.com/techne

ent Kit

)
3.0

Open

2.0.5

8.5

http://docs.oracle.com/cd/E13222_01/wl

Red Hat

Persistenc

http://hibernate.org/

Source
Open

Pivotal

e
Applicatio

http://projects.spring.io/sprin

Source

Software

g-framework/

Ibm

framework
J2EE
http://www-

Commerci
al

Container

01.ibm.com/software/webserv
ers/appserv/was/library/

Struts

2.0

Open

Apache

Web

Source

Software

framework

http://struts.apache.org/

Foundatio
n

274378801

Protected

Page 19 of 19