centricity business infrastructure part 1: overview

Imagination at work.

Derek Allen, GE Healthcare CHUG/CTC 2014

Centricity Business Infrastructure Part 2: Technical Details

Presenter

Derek Allen, Network Engineer

National Product Release Team (NPRT) Clinical Business Solutions GE Healthcare IT

[email protected]

2

Agenda

Review of Components

Review of Traffic Flows

Connectivity Configuration

Managing Multiple Environments

Unintended/Unsupported Configurations

Real-World Examples

Questions

3

Review of Components

4

Components – Advanced Web

Client Device (Windows PC) • Internet Explorer (web browser) used to access the application

Patient Database Server(s) • Caché Database containing patient data

• OpenVMS, HP-UX, AIX, Microsoft Windows running Ensemble/Caché

Web Server(s) • Presentation tier for client device, containing screen layouts, etc.

• Microsoft Windows running Internet Information Services (IIS)

Framework Database Server(s) • SQL Database containing user information, configuration settings, etc.

• Microsoft Windows running SQL

5

Review of Traffic Flows

6

Traffic Flows – Advanced Web

7

1. HTTP (PC to Web)

2. SQL (Web to CF DB)

3. CSVR (PC to Caché)

4. TELNET (PC to Caché)

5. CSP HTTP (PC to Web)

6. CSP (Web to Caché)

PC Web CF DB

(SQL)

Caché

Traffic Flows – Advanced Web

1. Client Device connects to Web Server using IE • Web Server provides initial login screen

• Web connection is maintained for loading controls, screen layout information, etc.

2. Web server connects to Framework Database Server • Framework Database Server verifies login information

• User configuration information sent back through Web Server to Client Device

3 & 4. Client Device connects to Patient Database Server • Direct TELNET & CSVR connections for patient data

5. Client Device creates CSP connection to Web Server • Web Server is running Caché Server Pages (CSP) Gateway software

6. Web Server connects to Patient Database Server • Web Server forwards CSP queries to Patient Database Server which responds back through

the Web Server to the Client Device

8

Traffic Flows – Load Balanced

9

1a. HTTP (PC to LB)

1b. HTTP (LB to Web)




5a. CSP HTTP (PC to LB)

5b. CSP HTTP (LB to Web)


PC LB

LB

Web

Web

Web

CF DB

(SQL)

CF DB

(SQL)

Caché

Caché

Traffic Flows – Encrypted

10

1a. HTTPS (PC to F5/A10)

1b. HTTP (F5/A10 to Web)


3a. Encrypted CSVR (PC to F5/A10)

3b. Unencrypted CSVR (F5/A10 to Caché)

4a. Encrypted TELNET (PC to F5/A10)

4b. Unencrypted TELNET (F5/A10 to Caché)

5a. CSP HTTPS (PC to F5/A10)

5b. CSP HTTP (F5/A10 to Web)


PC F5/A10

F5/A10

Web

Web

Web

CF DB

(SQL)

CF DB

(SQL)

Caché

Caché


1a. Client Device connects to F5/A10 VIP via HTTPS using IE • Web Server provides initial login screen

• Web connection is maintained for loading controls, screen layout information, etc.

• Connection via HTTPS instead of HTTP

• If desired, F5/A10 VIP can automatically redirect HTTP requests to HTTPS

1b. F5/A10 connects to Web Server via HTTP • Responses from Web Server are sent back through F5/A10 to Client Device

2. Web Server connects to Framework Database Server • Framework Database Server verifies login information

• User configuration information sent back through Web Server via F5/A10 to Client Device

• User configuration information sent to Client Device includes encryption settings

11


3a & 4a. Client Device connects to F5/A10 VIP • Encrypted CSVR & TELNET connections to F5/A10

3b & 4b. F5/A10 connects to Patient Database Server • Unencrypted TELNET & CSVR connections for patient data

• Responses from Patient Database Server are sent back through F5/A10 to Client Device

5a. Client Device sends CSP traffic via HTTPS to F5/A10 VIP

5b. F5/A10 sends CSP traffic via HTTP to Web Server • Web Server is running Caché Server Pages (CSP) Gateway software

• Responses from Web Server are sent back through the F5/A10 to the Client Device

6. Web Server connects to Patient Database Server • Web Server forwards CSP queries to Patient Database Server which responds back through

the Web Server via the F5/A10 to the Client Device

12

Connectivity Configuration

13

Browser URL

Browser URL determines which web server is accessed • Configured on each PC (as an icon, a shortcut, or favorite)

• Alternately configured on a virtual server (e.g. Citrix) accessed by PCs

• Alternately can be accessed as a link on a web portal

URL can be IP/name of specific Web Server or load balanced VIP • Fully Qualified Domain Name is recommended • e.g. “http://web1.xyz.com”

• If using encryption, load balancer can perform HTTP-to-HTTPS redirect • Client device’s shortcut uses HTTP in URL, but load balancer changes it to HTTPS

• e.g. “http://centricity.xyz.com” “https://centricity.xyz.com”

• Application will automatically append virtual directory (CFWeb or IDXWeb) • e.g. “http://centricity.xyz.com” “http://centricity.xyz.com/CFWeb/”

14

Browser URL

15

init.xml

init.xml determines which Framework Database is accessed • Configured on each web server (text file) • Default Path: C:\GEHC\Centricity Framework\Config\init.xml

• Previous Versions: C:\IDXPrograms\Web Framework\Config\init.xml

• Contains SQL Server name and SQL Database name

• Contains SQL username/password with sysadmin (sa) rights

• If modified, IIS must be restarted to reinitialize Centricity Framework for new settings to take effect

16

init.xml

<Server>

<Cache>Partial</Cache>

<Debug>N</Debug>

<Driver>com.microsoft.sqlserver.jdbc.SQLServerDriver</Driver>

<Db>sqlserver://cfsql.xyz.com;sendStringParametersAsUnicode=false;databaseName=CF;</Db>

<Usr>CFUSER</Usr>

<Pwd>cf1971f2dd009819b00b276eaccfcb4e4b7facda</Pwd>

<ConnectionPool>100</ConnectionPool>

<Catalog></Catalog>

<ShortTableNames>N</ShortTableNames>

<TextColumnType></TextColumnType>

<TimestampFormat></TimestampFormat>

<DataAccess></DataAccess>

<LoggingDateTimeFormat>UTC</LoggingDateTimeFormat>

</Server>

17

Framework Database Settings

Framework Database Settings determine: • CSP Gateway connectivity (Web Server IP & CSP Port, Namespace) • UCI determined by Namespace, since all UCIs share the same CSP port

• CSVR connectivity (Caché Server IP & CSVR Port) • UCI determined by unique CSVR Port (Namespace isn’t explicitly listed)

• TELNET connectivity (Caché Server IP & TELNET Port, Namespace) • UCI determined by Namespace, since all UCIs share the same TELNET port

Configuration • Configured for each “Framework System” on Connections tab • Allows multiple Framework Systems within a single Framework Database

• e.g. live, test, train, demo

• Framework System selected by user at login (or default)

• Changes to Framework settings take effect next time each user logs in

18


Configuration Steps 1. Log into Framework Database (Admin)

2. Select “Systems” from lefthand Vertical Toolbar

3. Select particular Framework System

4. Select Connections tab

19


20


21


22

CSP Gateway Configuration

Determines which Caché Server receives CSP traffic

• Configured on each Web Server running CSP Gateway • Newer versions: http://localhost/csp/bin/Systems/Module.cxw

• Older versions: http://localhost/csp/bin/cspmssys.dll

• Configuration | Application Access • Select “/csp” and “Edit Application” and click “Submit”

• “Default Server” field indicates which server settings are being used

• Configuration | Server Access • Select server identified in previous step, “Edit Server”, click “Submit”

• “IP Address” field indicates which Caché server is receiving CSP traffic

• “TCP Port” field indicates superserver port

23


24


25


26


27

Load Balancer Configuration

When traffic is sent to a Load Balanced VIP, the Load Balancer configuration determines which server receives that traffic

• Web VIP typically used for all web traffic (browser & CSP) • Web VIP points at all Web Servers in that environment (live, test, etc)

• Backend VIP may exist if CSVR/TELNET traffic sent through Load Balancer • CSVR & TELNET VIPs point at all Caché Servers in that environment (live, test, etc)

• Configuration details vary depending on Load Balancer platform

28

Traffic Flows – With Configuration Info

29

PC Web CF DB (SQL)

Caché

1. HTTP (PC to Web)






Browser URL init.xml

Framework Settings: Application – IDX Cache Server Pages

Framework Settings: Application – IDXtend Application - IDXML

Framework Settings: Application – IDXtend OS


Enabling Encryption

Connection Tab within each Framework System includes “SSLHost” & “SSLPort” fields for each traffic flow • Populating the SSLHost & SSLPort fields does *not* enable encryption

Setting the Preference “SSLEnabled” to “Y” enables encryption on all traffic flows within that Framework System • Until encryption is enabled, contents of SSLHost & SSLPort fields are ignored

Framework Settings take effect next time each user logs in • Users already logged in remain connected with their existing settings

Typically encryption is tested first in a new Framework System before being enabled within the Live Framework System(s)

30

Enabling Encryption

Example • Copy existing “CB Test” Framework System to create new “F5 Testing”

Framework System

• Populate “SSLHost” and “SSLPort” fields within “F5 Testing” Framework System (on Connections tab)

• Enable “SSLEnabled” encryption flag within “F5 Testing” Framework System (on Preferences tab)

Note: Other SSL-related preferences should be disregarded. They may remain in the database

when upgrading from a previous versions, but they are obsolete and therefore ignored.

31

Enabling Encryption

32

Enabling Encryption

33

Enabling Encryption

34

Enabling Encryption

35

Managing Multiple Environments

36

37

Scenario 1: Multiple Framework Systems Single Framework Server/Database

Multiple Framework Systems

Caché Server can be configured with multiple UCIs • Each UCI can be considered a unique Patient Database (Live, Test, etc)

• Each UCI is assigned a unique name (e.g. “LIVEUCI” or “TESTUCI”)

• Each UCI is assigned a unique CSVR Port (e.g. 2047 or 2050)

Within each Framework Database, multiple “Framework Systems” can be configured • Each Framework System can use different connection information • Allows pointing at different UCIs on same Caché server, different Caché Servers, etc

• Allows users to access servers via different IPs

• e.g. External users may need to use NAT IPs if internal IPs aren’t accessible

• Each Framework System can use different preferences • Allows encryption to be enabled/disabled, different color schemes, logos, etc

• Allows multiple environments (Live, Test, Train, etc) on same hardware

38


Example #1: Two separate Framework Systems within same Framework Database, using same Web Servers and same Caché Server, but pointing at two different UCIs (Live & Test)

Production Framework Database on Production SQL Server • Framework System Name: “CB Live” • Production Web Server: “web1.xyz.com”

• Production Cache Server: “cache1.xyz.com”

• UCI: “LIVEUCI”

• CSVR Port: 2047

• Framework System Name: “CB Test” • Production Web Server: “web1.xyz.com”


• UCI: “TESTUCI”

• CSVR Port: 2050

39


40


41

PC Web CF DB (SQL)

Caché

1. HTTP (PC to Web)






Browser URL http://web1.xyz.com

“CB Live” Framework System init.xml

cfsql.xyz.com

Framework web1.xyz.com

Namespace: LIVEUCI

Framework cache1.xyz.com CSVR Port: 2047 Framework

cache1.xyz.com Namespace: LIVEUCI

CSP Gateway cache1.xyz.com

LIVEUCI: 2047

TESTUCI: 2050


42

PC Web CF DB (SQL)

Caché

1. HTTP (PC to Web)






Framework web1.xyz.com

Namespace: TESTUCI

Framework cache1.xyz.com CSVR Port: 2050 Framework

cache1.xyz.com Namespace: TESTUCI


LIVEUCI: 2047

TESTUCI: 2050

init.xml cfsql.xyz.com

Browser URL http://web1.xyz.com

“CB Test” Framework System


Example #2: A third Framework System within same Framework Database, also pointing at Test UCI, but with encryption enabled and sending traffic through F5 VIPs

43


Production Framework Database on Production SQL Server • Framework System Name: “CB Live” • Production Web Server: “web1.xyz.com”


• UCI: “LIVEUCI”

• CSVR Port: 2047




• CSVR Port: 2050

• Framework System Name: “F5 Testing” • Production Web Server: “f5_web_vip.xyz.com” (F5 sends to web1.xyz.com)

• Production Cache Server: “f5_backend_vip.xyz.com” (F5 sends to cache1.xyz.com)


• Encrypted CSVR Port: 2550 (F5 sends to port 2050 on cache1.xyz.com)

44


45

Traffic Flows – “F5 Testing” Framework System

46

PC F5/A10 CF DB (SQL)

Caché


LIVEUCI: 2047

TESTUCI: 2050

Browser URL https://f5_web_vip.xyz.com

Framework f5_web_vip.xyz.com Namespace: TESTUCI

Framework f5_backend_vip.xyz.com

CSVR Port: 2550

Framework f5_backend_vip.xyz.com

Namespace: TESTUCI

f5_web_vip.xyz.com web1.xyz.com web2.xyz.com web3.xyz.com

Web

Web

Web

f5_backend_vip.xyz.com cache1.xyz.com

init.xml cfsql.xyz.com


How to log into a specific Framework System • Clicking the “Options” button on the login page brings up a popup window

• Otherwise if a specific Framework System is not selected at login, each user account is configured with a default Framework System

• Connection information (backend usernames/passwords) must be configured separately for each Framework System the user can access

47


48


49


50

51

Scenario 2: Multiple Framework Databases Multiple Framework Servers

Multiple Framework Databases

In addition to creating multiple Framework Systems within one Framework Server/Database, it can be useful to create multiple Framework Databases (separate Framework Database Servers)

• Creates isolated, separate environments for testing • Different physical servers to apply patches, change settings, etc

• Separate Framework Databases allow multiple application versions • All Framework Systems within one Database must be on same application version

• Typically the Test Server performs dual functions of Web & SQL DB Server • Test environment usually doesn’t require dedicated hardware for SQL

Common practice to copy Live Framework DB to Test DB Server • Automatically copies existing users, application settings, Framework Systems, etc

• Can cause confusion, because resulting Test Framework DB identical to Live Framework DB

• Same Framework System names, pointing at live Web Servers & live Caché Server after copy

• Before using Test environment, must modify Test Framework Settings to point at test servers

52


53

PC

Live Web

Live CF DB

Live Caché

Test Web

Test Caché

Test CF DB

Live Caché

Live CF DB

Live Web


54

PC

Live Web

Live CF DB

Live Caché

Test Web

Test Caché

Live Caché

Live CF DB

Live Web

Test CF DB


Example: Two separate Framework Databases, used by separate Web Servers on different versions of Centricity Business

Production Framework Database on Production SQL Server • Centricity Business Version 4.3




• CSVR Port: 2050

Test Framework Database on Test SQL Server • Centricity Business Version 5.0

• Framework System Name: “CB Test 5.0” • Test Web Server: “testweb.xyz.com”

• Test Cache Server: “testcache.xyz.com”

• UCI: “UPGRADE”

• CSVR Port: 2048

55


56


57

PC

Live Web

Live CF DB

Live Caché

CSP Gateway

Test Web

Test Caché

Test CF DB

init.xml

Live Framework

Browser URL (Live)

Live Framework

Live Framework

web1.xyz.com

cache1.xyz.com

TESTUCI: 2050


58

PC init.xml

Test Framework

Test Web

Test Caché

Test CF DB

CSP Gateway

Browser URL (Test) Live

Caché

Live CF DB

Live Web

Test Framework

Test Framework

testweb.xyz.com

testcache.xyz.com

UPGRADE: 2048

59

Scenario 3: Multiple Framework Databases Single Caché Server


Single Caché Server • It is common for multiple environments (e.g. Live & Test) to have separate

Web Servers, but to share the same Caché Server

• This is easily handled by pointing the CSVR & TELNET Framework Settings at the appropriate Caché IP, CSVR Port, and Namespace

Example • Live Web & Live SQL DB point at LIVEUCI & port 2047 on Caché Server

• Test Web & Test SQL DB point at TESTUCI & port 2050 on Caché Server

Note: This example is similar to the initial example for Multiple Framework Systems, but that

example used the same Live Web/SQL Servers, while this example has separate Live Web/SQL

Servers and Test Web/SQL Servers

60


61

PC

Live Web

Live CF DB

Live Caché

Test Web

Test Caché

Test CF DB

Caché


62

PC

Live Web

Live CF DB

Caché

CSP Gateway

Test Web

Test CF DB

init.xml

Live Framework Port 2047

Browser URL (Live)

Live Framework LIVEUCI

Live Framework LIVEUCI


63

PC init.xml

Test Web

Caché

Test CF DB

CSP Gateway

Browser URL (Test)

Live CF DB

Live Web

Test Framework TESTUCI

Test Framework Port 2050

Test Framework TESTUCI

64

Scenario 4: Multiple Framework Databases Multiple DBs on a Framework Server


Multiple Databases on a Framework Server • Although each Framework Database can exist on its own SQL Server, there

is no reason that multiple databases can’t coexist on a single server

• The most common use is to create multiple Test environments using a single Test SQL Server (to minimize the number of servers to support)

• Normally the Live/Production Framework Database exists on a separate SQL Server than the Test Framework Database for performance & reliability

Example • Rather than Test Web Server 1 pointing at a DB on Test SQL Server 1, and

Test Web Server 2 pointing at a DB on Test SQL Server 2, both Test Web Server 1 and Test Web Server 2 can point at two different DBs existing on the same Test SQL Server

65


66

PC

Test Web

Caché

Test1 CF DB

Live CF DB

Live Web

DB1

DB2

Test1 Web

Test2 Web

Test2 CF DB


67

PC

Test Web

Caché

Test1 CF DB

Live CF DB

Live Web

DB1

DB2

Test1 Web

Test2 Web

Test2 CF DB

init.xml

Browser URL (Test1)


68

PC

Test Web

Caché

Test1 CF DB

Live CF DB

Live Web

DB1

DB2

Test1 Web

Test2 Web

Test2 CF DB

init.xml

Browser URL (Test2)


69

PC

Test1 Web

Caché

Test1 CF DB

Live CF DB

Live Web

DB1

DB2

Test2 Web

DB1

DB2 Test2 CF DB

Test CF DB


70

PC init.xml

Test1 Web

Caché

Test CF DB

Browser URL (Test1)

Live CF DB

Live Web

Test2 Web

DB1

DB2


71

PC

Test1 Web

Caché

Test CF DB

Browser URL (Test2)

Live CF DB

Live Web

Test2 Web

DB1

DB2

init.xml


72






Possible Unintended Configuration: • Remembering to modify Framework settings to repoint CSVR/TELNET at Test Caché Server

• Forgetting to modify Framework settings to repoint CSP traffic at Test Web Server (CSP is still

pointing at Live Web server)

Result: • CSVR/TELNET traffic sent to Test Caché Server due to correct Framework Settings

• CSP traffic sent to Live Caché Server (via Live Web Server) due to incorrect Framework Settings

• Conflicting data between Test Caché Server and Live Caché Server causes errors

73


74

PC init.xml

Test Framework (incorrect CSP setting)

Test Web

Test Caché

Test CF DB


Caché

Live CF DB

Live Web

Test Framework (correct CSVR setting)

Test Framework (correct TELNET setting)

CSP Gateway






Possible Unintended Configuration: • OK if Live Framework Database and Test Framework Database are on different versions

• But copying Live Database to Test will result in an application version mismatch, since the Test

Web Server application version is different than Test Framework Database version

• Result:

• Errors when logging in via Test Web Server due to incorrect Framework Database format

75


76

PC

4.3 Web

Test Caché

4.3 CF DB

Live Caché

4.3 CF DB

4.3 Web

5.0 Web

5.0 CF DB

4.3 CF DB

SQL Copy


77

PC init.xml

5.0 Web

Test Caché

4.3 CF DB


Caché

4.3 CF DB

4.3 Web


Possible Unintended Configuration • Incomplete Encryption Configuration – not all traffic is encrypted

Example • SSL enabled on Web Server (or on load balanced VIP for Web Servers)

• Browser uses encrypted HTTPS URL, which encrypts the browser-based traffic

• But if encryption flag remains disabled within Framework settings, CSVR/TELNET/CSP traffic

is *not* encrypted

• The browser window will provide visual indication the browser-based traffic is encrypted

• However, Protected Health Information (PHI) is sent over non-browser connections via

ActiveX controls (CSVR, TELNET, CSP) which are *not* automatically encrypted by browser

78

Encryption – Correct Configuration

79

PC F5/A10

F5/A10

Web

Web

Web

CF DB (SQL)

CF DB (SQL)

Caché

Caché




3a. Encrypted CSVR (PC to F5/A10)


4a. Encrypted TELNET (PC to F5/A10)


5a. CSP HTTPS (PC to F5/A10)



Encryption – Incomplete Configuration

80

PC F5/A10

F5/A10

Web

Web

Web

CF DB (SQL)

CF DB (SQL)

Caché

Caché




3a. Unencrypted CSVR (PC to F5/A10)


4a. Unencrypted TELNET (PC to F5/A10)


5a. CSP HTTP (PC to F5/A10)



Encryption – Incomplete Configuration

81

Real-World Examples

82

Centricity Business Environment – Live & Test

83

Live Web

Live Web

Live Web

Live Web

Live Web

Live Web

Test CF DB (SQL)

Live CF DB (SQL)

Test Caché

Live Caché

Test Web

Test Web

Test Web

Test Web

IDXWF

init.xml IDXWF

CSVR & TELNET

CSVR & TELNET

init.xml

CSP GW

CSP GW

PC

LB

Testing New Centricity Business Version

Goals • Provide test environment for new version of Centricity Business

• Maintain existing test environment for current version of Centricity Business

Reconfiguration • Create new “IDXWF_50” Framework Database on Test SQL Server by copying existing

“IDXWF” Framework Database

• Upgrade the new “IDXWF_50” Framework Database to the new version of CB

• Upgrade 2 of the 4 Test Web Servers to the new version of CB

• Point the 2 upgraded Test Web Servers at the “IDXWF_50” Framework Database (via init.xml)

End Result • 2 Test Web Servers are on the new version of CB (pointing at “IDXWF_50”)

• 2 Test Web Servers are on the existing version of CB (pointing at “IDXWF”)

84

Live Web

Live Web

Live Web

Live Web

Live Web


85

Live Web

Test CF DB (SQL)

Live CF DB (SQL)

Test Caché

Live Caché

init.xml IDXWF

CSVR & TELNET

IDXWF

CSVR & TELNET

Test Web

Test Web

Test Web

Test Web

init.xml

CSP GW

CSP GW

PC

LB

IDXWF

IDXWF_50

Test Web

Test Web 5.0

Test Web

Test Web

init.xml

CSP GW

init.xml

CSP GW

Live Web

Live Web

Live Web

Live Web

Live Web


86

Live Web

Test CF DB (SQL)

Live CF DB (SQL)

Test Caché

Live Caché

IDXWF

CSVR & TELNET

CSVR & TELNET

init.xml

CSP GW

PC

LB

IDXWF

IDXWF_50

Test Web

Test Web 5.0

Test Web

Test Web

init.xml

CSP GW

init.xml

CSP GW

Testing New Caché Business Version

Goals • Provide test environment for new version of Caché

• Maintain existing test environment for current version of Caché

Reconfiguration • Install/configure new Test Caché Server

• Create new “IDXWF_2008” Framework Database on Test SQL Server by copying existing


• Change the Framework System settings within the “IDXWF_2008” Framework Database to point at the new Test Caché Server

• Point 2 of the 4 Test Web Servers at the “IDXWF_2008” Framework Database (via init.xml)

• Reconfigure CSP Gateway on the 2 Test Web Servers to point at the new Test Caché Server

End Result • 2 Test Web Servers are using the new Test Caché Server (pointing at “IDXWF_2008”)

• 2 Test Web Servers are using the existing Test Caché Server (pointing at “IDXWF”)

87

CSVR & TELNET

Testing New Caché Version

88

Test CF DB (SQL)

Live CF DB (SQL)

Test Caché

Live Caché

Test Web

Test Web

Test Web

Test Web

IDXWF init.xml

CSVR & TELNET

CSP GW

init.xml

CSP GW

init.xml

CSP GW

IDXWF

IDXWF_2008

Test Caché 2008

CSVR & TELNET

Live Web

Live Web

Live Web

Live Web

Live Web

Live Web

PC

LB

Test Web

Test Web

Test Web

Test Web

IDXWF init.xml

CSP GW

Test Web

Test Web

Test Web

Testing New Caché Version

89

Test CF DB (SQL)

Live CF DB (SQL)

Test Caché

Live Caché

Test Web

IDXWF

IDXWF init.xml

init.xml

CSVR & TELNET

CSVR & TELNET

CSP GW

CSP GW

IDXWF_2008 init.xml

CSP GW

Test Caché 2008

Live Web

Live Web

Live Web

Live Web

Live Web

Live Web

PC

LB

Minimize Downtime During POL Upgrade

Issue • During Patient Online (POL) upgrade, the Live Framework Database will be down for 6 hours

Goals • Minimize downtime for CB users

Reconfiguration Pre-Upgrade • Schedule short 30 minute downtime for Centricity Business users

• Create new “IDXWF_Downtime” Framework Database on Live SQL Server by copying existing


• Repoint 3 of the 6 Live Web Servers at the “IDXWF_Downtime” Framework DB (via init.xml)

• Reconfigure the Load Balancer to only send traffic to the 3 “Downtime” Live Web Servers

Upgrade • The 3 offline Live Web Servers and the “IDXWF” Framework Database can be upgraded

90

Minimize Downtime During POL Upgrade

Reconfiguration Post-Upgrade • Schedule another short 30 minute downtime for Centricity Business users

• Reconfigure the Load Balancer to only send traffic to the 3 upgraded Live Web Servers

Cleanup • The remaining 3 “Downtime” Live Web Servers can be upgraded and repointed at “IDXWF”

• The “IDXWF_Downtime” database can be deleted

• Any Framework Database changes (application settings, passwords, etc) made during the

upgrade will be lost

• Once the remaining 3 Live Web Servers have been upgraded they can be added back on the

Load Balancer

End Result • Two short (30 minute) downtimes instead of one long (6 hour) downtime

• Users were informed that no application settings should be changed during the upgrade

• Any passwords changed during the upgrade will need to be reset by the helpdesk

91

Test Web

Test Web

Test Web

Upgrading Patient Online (POL)

92

Test CF DB (SQL)

Live CF DB (SQL)

Test Caché

Live Caché

Test Web

IDXWF init.xml

CSVR & TELNET

CSVR & TELNET

CSP GW

IDXWF

IDXWF_Downtime

Live Web

Live Web

Live Web

Live Web

Live Web

Live Web

PC

LB

init.xml

CSP GW

CSP GW

init.xml

IDXWF

Live Web

Live Web

Live Web

Live Web

Live Web

Live Web

init.xml

CSP GW

Test Web

Test Web

Test Web


93

Test CF DB (SQL)

Live CF DB (SQL)

Test Caché

Live Caché

Test Web

IDXWF init.xml

CSVR & TELNET

CSVR & TELNET

CSP GW

IDXWF

IDXWF_Downtime

Live Web

Live Web

Live Web

Live Web

Live Web

Live Web

PC

LB

init.xml

CSP GW

CSP GW

init.xml

Live Web

Live Web

Live Web

IDXWF

Test Web

Test Web

Test Web


94

Test CF DB (SQL)

Live CF DB (SQL)

Test Caché

Live Caché

Test Web

IDXWF init.xml

CSVR & TELNET

CSVR & TELNET

CSP GW

Live Web

Live Web

Live Web

Live Web

Live Web

Live Web

PC

LB

init.xml

CSP GW

CSP GW IDXWF_Downtime

init.xml

Live Web

Live Web

Live Web

Live Web

Live Web

Live Web

IDXWF init.xml

init.xml

Test Web

Test Web

Test Web


95

Test CF DB (SQL)

Live CF DB (SQL)

Test Caché

Live Caché

Test Web

IDXWF init.xml

CSVR & TELNET

CSVR & TELNET

CSP GW

PC

LB CSP GW

CSP GW

Live Web

Live Web

Live Web

Live Web

Live Web

Live Web

IDXWF init.xml

Live Web

Live Web

Live Web

Live Web

Live Web

Live Web

CSP GW init.xml

Test Web

Test Web

Test Web


96

Test CF DB (SQL)

Live CF DB (SQL)

Test Caché

Live Caché

Test Web

IDXWF init.xml

CSVR & TELNET

CSVR & TELNET

CSP GW

PC

LB

IDXWF init.xml

Live Web

Live Web

Live Web

Live Web

Live Web

Live Web

CSP GW

Questions

97

Portions of this presentation General Electric reserves the right to make changes in

specifications and features, or discontinue the product or service described at any time, without notice or obligation. This does not constitute a representation or warranty or

documentation regarding the product or service featured. Illustrations are provided for

informational purposed, and your configuration may differ.

This information does not constitute legal, financial, coding, or regulatory advice in connection

with the use of the product or service. Please consult your professional advisors for any such

advice. Operation of GE Healthcare products should neither circumvent nor take precedence

over required patient care, including human intervention of healthcare providers. GE

Healthcare products and services do not code medical procedures. Accurate coding is the

responsibility of the provider or billing professional.

GE, the GE Monogram, Centricity and Imagination at Work are trademarks of General Electric

Company.

©2014 General Electric Company – All rights reserved.

98

centricity business infrastructure part 1: overview

Documents