Upload
brian-petrini
View
33
Download
2
Embed Size (px)
Citation preview
© 2015 IBM Corporation0
Best Practices: BPM Implementation, Migration and Upgrade
Allen Chan, IBM BPM Lead Architect – Install, Config and MigrationBrian Petrini, IBM BPM Technical Product ManagerJerome Boyer, IBM Software Services, Implementation Methods
Agenda
• BPM 8.5.6
• Upgrade Approches
• Migration Approches
• Top Practices
1
Act in context with data Drive simplicity and speed with cloud
Accelerate customer engagement
Highlights of What’s New in Business Process Manager v8.5.6 & Business Monitor
§ Watson integration samples
§ Embedded content store
§ Embedded rules
Product Foundation
§ BPM Developer Center
§ Federated Portal• Seamlessly blend tasks from
multiple BPM servers across versions (v8.0+)
§ Asset to Isolate Process Applications (start, stop, move)
§ Business Monitor updates§ IBM PureApplication®System
pattern released§ Expanded operating system
coverage§ Dashboard customization with
Rapidly Adaptive Visualization Engine
§ BPM on Cloud• Tiered Pricing• Data center support in
Japan and Hong Kong
§ Workflow Service on Bluemix
§ Mobile Responsive Portal
§ Case Management • Case Linking
§ Enhanced FileNet Content Manager support
§ Responsive Coaches
§ Click to create Worklight projects
§ REST API for custom mobile application development
Key: New feature Previously released feature
WPS Upgrade & Migration Paths
From ToVersion EOS BPM BPM BPM BPM BPM BPM
751x 800x 801x 850x 855 856WPS 602 09/2010
WPS 610 04/2013 Yes
WPS 612 09/2013 Yes
WPS 620 04/2014 Yes Yes Yes Yes Yes Yes
WPS 700 04/2015 Yes Yes Yes Yes Yes Yes
migrationupgrade
For WPS 602 and 61x, we currently do not provide a direct upgrade path for runtime migration (i.e. preserve existing process instances) to BPM 8xx. However, customers can still use IID 8xx and manually update the applications to get it working on the latest BPM level, and then use the “drain” approach (see later charts for details).
WLE Upgrade & Migration Paths
From ToVersion EOS BPM BPM BPM BPM BPM BPM
751x 800x 801x 850x 855 856TW 61x 09/2013 Yes Yes Yes As
neededAs needed
As needed
TW 62x 09/2013 Yes Yes Yes Yes Yes YesWLE 71 09/2013 Yes Yes Yes Yes Yes YesWLE 72 04/2016 Yes Yes Yes Yes Yes Yes
migrationupgrade
BPM Upgrade & Migration Paths
From ToVersion EOS BPM BPM BPM BPM BPM BPM
751x 800x 801x 850x 855 856BPM 750 09/2016
expected
Upgrade Yes Yes Yes Yes Yes
BPM 751 09/2016expected
Upgrade Yes Yes Yes Yes Yes
BPM 800 09/2017expected
Upgrade Upgrade Yes Yes Yes
BPM 801 09/2017expected
Upgrade Yes Yes Yes
BPM 850 n/a Upgrade Upgrade Upgrade
migrationupgrade
6
Migration Improvements
Infrastructure migration/updateIn 8.5 we drastically simplified the infrastructure, improving the standardization and as a result improved the testing coverage. We went from 9700 permutations to about an order of magnitude fewer. Likewise we went to a central configuration file (BPMConfig).To help with migration we have created config extraction tools that take from older versions, display the configuration graphically for modification, and allow creation of new environments from this file.For ifixes and fixpacks, we have been working on simplifying the ifix updates so that include the dependency trees, making applying them simpler.Migration checklist - we now include a migration checklist to check for the infrastructure.DB clone - since 8.5.5 we support DB cloning for migration. This greatly reduces risk as customers can migrate to a cloned DB and if there are any issues they can just point to the original DB.
Fixpack strategy - Since 8.5.0 we have been including all fixes in the next feature release. This increases quality for our customers as we are reducing the number of code streams that we have to support and test, allowing us to be more thorough testing.
7
Migration Improvements
Application migrationWe have been stabilizing the programming models over the last 4 years, making fewer changes in each release. As a result, application migration is simpler for customers moving from later releases.
App-by-app migrationIn 8.5.6 we will introduce as a services asset the app-by-app migration. This will give business more flexibility as they won't have to migrate the entire infrastructure, but rather could focus on one or two process applications that need the latest infrastructure.
Instance MigrationWe continue to improve the performance of instance migration which will allow for shorter time windows when applications are updated and older instances are migrated to the latest snapshot. In the latest release it is an order of magnitude faster than in 8.5.6 due to parallelism in both local threads and multiple nodes.
8
18 month entitlement
LicenseWe recognize that the SWG standard of 90 day dual entitlement may not suffice for large BPM deployments doing BPM Version to Version system migrations with long running processes and in this case have a pre-approved, 18 month extended migration agreement that can be offered. Link to information: http://www-01.ibm.com/software/integration/business-process-manager/library/entitlement-migration-bpm/
9
Reducing the need for migration
• Upgrade strategy - Since 8.5.0, we have followed an "update only" constraint on every new 8.5 release. This has resulted in upgrade only infrastructure since 8.5.0 (June 2013) that will continue until we reach BPM 9. This is at least 3 years of upgrades only. Compare that to the previous years where we forced a migration each year (every release).
• Federated API/Portal - In 8.5.6 we are introducing a federated portal that aggregates the information from cells of different BPM versions. This is key to our strategy going forward as we release new versions. This way you can let their existing applications and process instances drain from older cells and start new processes in the new cell. This would greatly reduce the need for application migration.
Upgrade Approaches
10
Upgrade Rules of Thumbs1. You can use a “rolling upgrade” methodology to upgrade your BPM ecosystems.
a. In-place Rolling Upgradeb. Side-by-side Rolling Upgrade
2. Do not upgrade your Process Center (Dev environment) until you have at least proved that the upgrade is working in your QA environment.
3. The version of Process Designer and Integration Designer must match the version of the Process Center.
4. The version of Process Center and Process Server must match in order for the Process Server to be connected as “online”.
5. An application that you developed using an older version of the BPM product can be deployed to run on a newer version of BPM as long as it is not using features that have been removed.
6. We strive to maintain API compatibility in BPM mod and fixpack releases. 7. In BPM 85xx, we enabled the support of online rolling upgrade:
a. BPM 8500 Process Designer and Integration Designer to connect to BPM 8501 of Process Center and Process Server (for debugging).
b. A BPM 8501 Process Server can connect as “online” mode to BPM 8500 Process Center.
c. The purpose to facilitate debugging of upgraded application and allow a more gradual roll out of the upgrades.
Process – In-Place Rolling Upgrade
startCertify PS<Test> end
Certify PS<Staging>
Certify PS<Prod> Certify PC
In this procedure, we will upgrade PS first.. From <Test> to <Prod>, and finally upgrade PC.
Pros:1.Upgrade and certify one Process Server environment at a time in an orderly fashion.2.Upgrade PC last as we want to ensure we can continue to provide fixes to PS running at current version.
Cons:1.Upgrade PC last means developers cannot utilize new features until the entire eco-system is upgraded.2.With the exception of 8501 (Fuji), any other upgrade would force the PS to go offline to the down-level PC, thus requiring offline deployment until the PC is upgraded.
We should always take a full backup of your environment before the upgrade, this allows up to restore any environment during this period in order to deliver a hot-fix of your application to your <Prod> environment before your <Prod> environment can be upgraded.
Process – Side-by-Side Rolling Upgrade
startSide-by-side“upgraded”
PC
Certify andRe-target PS<Test>
Certify andRe-target PS<Staging>
Certify PS<Prod>
In this procedure, we will setup a new “upgraded” PC side-by-side, and then proceed to upgrade each of the PS enviroment.
Pros:1.An “upgraded” PC is available immediately for new development and tests2.Customers can certify new product version on a per-application basis without impacting existing development and test.3.All Process Server environments can maintain “online” status all the time.
Cons:1.Setup a side-by-side “upgraded” PC will require additional IT resources and may incur additional licensing cost.2.May require more work if the customers’ configuration is not well documented.3.Depending on the approach to setup the side-by-side PC, one will lose existing “playback”instances data.
Sunset old PC end
Managing fixpack upgrade downtime
By performing some upgrade tasks in parallel, we can reduce the time it took to upgrade. In this example, we are upgrading to 7.5.1.2.
Upgrade from 7.5.1.x to 7.5.1.2 Time
• update Installation Manager• backup configuration
1 – 2 min (in parallel)
• update Deployment Manager and Nodes using a “staggering”approach with 10 min delay between each node.
60 min
• upgrade clusters• upgrade database
10 min
Total 72 min*
•Time is taken based on a test system with 3 nodes. The actual time will depend on a number of factors such as disk access time, network latency, CPU speed, etc.• For upgrade from 7.5.0.0, you can expect more time is needed for updating the individual node.
Migration Approaches
15
Engage IBM EAS and ISSW for a migration assessment and assistant
Plan your migration
16
Plan your migration
1. Understand YourReqts and Environment
2. Migration Assessment
Team Regular Communication
3. Identify Project Teamand Project Plan
4. Develop MigrationStrategy and Documents
7. Test Migration and Recovery Plan
5. Migration and TestYour Applications
6. Clean up Source Environment
8. Go Live Planningand Execution
Landscape
1- Current product version used to support existing production applications
CurrentProcess Server(Test/ Staging/ Production)
CurrentProcess Center
2- New applications are developed on new version.
New DevProcess Server
NewProcess Center
New Process Server(Test/Staging/Production)
1
2
4
3
3- Export/import Toolkit for refactoring
4- Migrate artifacts and/or business data
5- Deploy new and migrated apps 5
Migration Approach
Drain - Application migration and “drain” existing instances • Let existing instances in V-old run to completion, start new instances in V-new system.
Milestone Transfer - Transfer process state mid-stream using custom logic to new version.• A variation of the “Drain” approach.• Let existing instances in V-old run to a designated set of business milestones, start new instances in V-new system from those milestones.
Runtime Migration - Application migration followed by Runtime migration • Once ALL applications are working in V-new, convert the existing database to make it compatible with V-new in one shot.
What to Migrate?
Pros ConsArtifacts Only Migration(Drain orMilestone Transfer)
Start with a clean database. Leave messy data behind.
Parallel production environment allows for app-by-app migration and no production downtime.
Process history are not transferred to the new system.
Parallel production environment requires additional maintenance and resources.
Business Data and Applications Migration(Runtime Migration)
Source environment applications and data are migrated to the target environment.
Process and human tasks can start in the source environment and complete in the target environment.
Bringing over all data depending on size and complexity can increase migration risks which requires additional testing.
Downtime required. All applications must be ready before you can start migrating the system.
Process Center Migration
Observing that Process Center contains “playback” instances only, there is really no business needs to migrate “playback” instances to the new product version. Based on this assumption, we are simplifying the Process Center migration to application-only migration.
• Setup a new PC target environment with new database.• Migrate individual application artifact by exporting “active” snapshots from source environment to target environment in chronological order.• Runtime data (instances, tasks, tracking groups, etc) and offline server deployment information will not be migrated.
Advantages:• One can setup Process Center right away and start working on application migration.• Application can be moved to new product version one application at a time.• Existing V-old Process Center is still available to handle fixes for production system.• No downtime for Process Center.
Not applicable if Process Center is notused in your system.
Migration Enhancement
21
BPM 8.5.5/8.5.6 Migration EnhancementImprove migration robustness, ease-of-use and planning• Revised documentation with enhanced interactive migration guide and guidance on migration methodology to better guide customers and services on how to plan their migration project.
• Migration Pre-Validation Tool + Post-Validation Health Center• Pre-check and report migration potential failures• Save cost of migration late phase failure, recovery and redo• Post-Validation via BPM Health Center, speed up target environment health check
• Easier environment setup via Configuration Migration Tool• Migration paths support with a target environment that is set up with about 400 source-environment basic properties around database, security, and the most important performance parameters to the client’s environment.
• Reduce about 50% post-migration actions on properties• Separate tool can export/import WAS application level configurations which are not owned by the BPM, like: data source, auth-alias, SSL settings
Speeding up migration • Quicker migration via multi-thread enablement
• Migration from BPM v7.5.1 migration shows 2x ~ 3x improvements• Migration from TW v6.2 migration can see up to 20x improvements
22
Interactive Migration Guide• Help you determine the expected document that matches your migration scenario, save your effort to search infocenter and navigate between different topics.
23
Two steps wizard
Validate source environment before migration• We introduced migration pre-validation tool to help you find potential issues before real migration, and what you should take care during migration
• Validate current environment to make sure it’s ready to do migration
• Read required information that will be used in latter migration steps
• Show error if it’ll block migration, or the source environment isn’t in the expected status
• Show warning if you need to take care before or after migration• Show warning if there is some big number of data will have performance impact during migration
24
Validate source environment before migration• Report sample 1 for migration prevalidation
25
Validate source environment before migration• Report sample 2 for migration prevalidation
26
Understand configuration migration• Source environment information
• Map to the supported target based on what your source environment was.• Make sure it’ll reuse old database on the target.
• Security• Federated LDAP• LTPA• File registry
• Performance tuning• Customized XML files (e.g. 100Custom.xml)
• Some properties will be moved to WCCM• Keep remaining customization and copy to each node on the target
• Business Process Choreographer• Business Flow Manager• Human Task Manager
27
Understand configuration migration
28
Source Target
Move configuration
Edit the exported properties file using Configuration Editor
BPMConfig -migrate BPMConfig -create
• WebSphere Process Server 6.2.x or 7.0.0.x
• WebSphere Lombardi Edition 7.1 or 7.2
• IBM Business Process Manager 7.5.x or 8.0.x Express/Standard/Advanced
• IBM Business Process Manager 8.5.6.0 Express/Standard/Advanced/AdvancedOnly
Understand database upgrade• For Standard database: Process Server and PDW database
• DBUpgrade will cover both schema update and data transform• Tune the script to get better performance (thread or batch size)
• For Advanced database: Common/BPC/BusinessSpace• upgradeSchemaAll will run all required upgrade SQL files• upgradeSchemaAll will also run the initialization SQL for newly added capability if any
• Support to test and validate migration using cloned database• BPMMigrate will update the topology information in the database
• Import SIB messages to the target• Recreate WAS scheduler tasks
29
Understand database upgrade
30
Do other configuration customizationEstimate migration window...
Source
TargetCloned
Target
Cloned ClonedClone database
BPMConfig –update -dataSource
Test database upgrade using cloned database, and finally retarget your current environment to the original database to do the last run.
Test migration against cloned databases
Understand database upgrade• Performance improvement on database upgrade
• DBUpgrade have much performance improvement, and you can add more threads to handle the transform of large number of instance and task
31
Wang Lei ok, thanks 4:53:22 PM
Cleaning up before migrationThe more data we have in the BPM system, the longer it will take
migration to run. So it is important that before we run migration, remove information that are not required anymore in the new system.
• ProcessInstancesCleanup command to remove “completed” process instances.
• Performance Data Warehouse prune command for removing PDW data.
• BPMDeleteDurableMessages command to remove durable events that are no longer needed.
32
BPM Health Center• Check the health status of the deployment environment after migration, should be the first step to validate migrated environment before other planned testing
33
App-by-App services asset for BPM StandardSupport selective migration of applications runtime data1. Selective migration
1. Only move certain applications2. Only move the data which need keep in the new environment by the time range3. Only move the system data like users, groups, user-group-relationship, user attributes, etc
2. Splitting of deployment systems1. Refine the deployment design2. Scaling out application
3. Database vendor conversion - other databases move to DB2
What this is not intended for: 1.Temporary move of applications for the isolation and then moved back2.Massive restructuring of the BPM environments3.Move applications freely among different BPM environments4.Move advanced data (BPEL)
34
App-by-App compare with runtime migration
Pros ConsApp-by-app Migration
1. Migrate one BPM Standard application at a time to the new system to reduce migration risk.
2. Support database conversion to DB/2 from Oracle or SQL Server.
3. Support limited migration undo.4. Enhanced Pre-validation before
migration.5. Minimum system downtime (restart
target system after migration, stop event manager during migration)
1. Support BPM Standard only. Advanced content is not migrated.
2. DB2 for z/OS databases are not supported.
3. Available as Services Asset only at this point.
Business Data and Applications Migration(Runtime Migration)
1. Support both BPM Standard and BPM Advanced.
2. Source environment applications and data are migrated to the target environment.
3. All historical information is preserved
1. Bringing over all data depending on size and complexity can increase migration risks which requires additional testing.
2. Full Downtime required. All applications must be ready before you can start migrating the system.
Migration Top Practices
36
IBM Services Migration Project Roadmap
Goal:• To provide a high-level
understanding of migration options;;• Capture the information that is
relevant to the migration• Recommend next steps.
Steps: • Review current infrastructure &
project goal
Input:• Migration Discovery Questionnaire
Output:• A documented understanding of the
current infrastructure;; a commitment by the client to invest their time in a Migration Assessment/Pilot
Goal:• To provide ROM estimates for
migrating selected process applications and service integrations in a ‘like for like’ fashion from the current environment to the target environment
Steps:• Process Application business and
functional review• Process App. architectural review• Process App. source code review
Output:• High level migration approach• ROM estimation
Goal:• To migrate selected process
applications and service integrations from the current to target environment
Steps: • Install and configure selected
environments and tools• Migrate code to the new
environment• Perform testing & defect
resolution
Output:• Migrated applications and
environment• Team enabled
Discovery CallDuration: 2 hours
Discovery WorkshopDuration: 1 to 2 daysNo charge
ImplementationDuration: varies, depending on scope and complexity
Questionnaire: 30 questions to discover the potential scope
• Version• Runtime• Application• Operational model• Test
• Converged with WAS migration questionnaire
38
Migration Workshop
Goals Review the migration baseline Define application and asset inventory.Identify customizationsReview current physical architectureAssess Hardware / Software requirementsReview deployment strategyDefine migration validation strategy
Define migration approach Determine runtime migration approachRecommend solution architecture.Recommend BPM topologyIdentify key improvement opportunities enabled by new/enhanced product features.Define staffing skills needed
Determine next steps Workshop report with recommendations and findingsRough Order Of Magnitude estimate and project approach (WBS)Define the best migration approach
Who IBM Migration Specialist<IBM BPM Developer>IBM Client Partner
IT ArchitectBPM DeveloperProject manager
Format 1 to 2 days No charge39
Top Practices for Successful Migration• Minimize Refactoring – we are often tempted to make significant changes to the applications as part of a migration project. This can lead to un-intended delay in projects or make it impossible to migrate runtime data.
• Having a comprehensive regression test plan, including non-functional tests such as stress and performance tests, can help eliminate surprises in the project.
• Review and playback often and regularly with business and IT stake holders, this avoids last minute surprises such as user experience expectation, security concerns, etc.
• Use good quality data for in-flight migration testing (UAT or production databases). Database from development environment contains a lot of development “noise” which causes problems
40
Top Practices for Successful Migration• Test database upgrade using cloned database of production environment, estimate migration windows and verify the migrated environment
• Carefully test migrated instances for each Application. Some problems can be revealed only with specific development patterns unique to specific process application (e.g. serialization changes between TW6 and BPM8 affected event correlation)
• There is no fixed formula to estimate the time up front as the migration depends on a number of factors such as number of process instances, tasks, users, groups, durable subscriptions, tracking groups, size of your data and execution context, etc.
• Applications should be upgraded and running correctly in target system at least 2 months before go-live date. Migration and Performance testing should start as soon as possible, not just a couple weeks before go-live.
41
Other special considerations• Account of changes in security model early – want to switch to LDAP from file-based repository?
• Account for non-standard cluster configuration if you’re not following the IBM recommended golden topology for your setup.
• BPM + Monitor. If your source BPM environment is augmented with Monitor in the same cell, but in BPM 8550/8560, we don’t support BPM and Monitor in the same cell any longer, you have to follow two separate procedures to migrate BPM and Monitor to separate cells on BPM 8550/BPM 8560.
42
Other special considerations• Test the cases that some instance arrives at an activity that waiting for some event (UCA), make sure the messages can still be consumed after migration.
• If you’re migrating from multiple deployment environments, you need to do the migration procedure for each of your deployment environment.
• Port number maybe changed after migration, you need to update them manually or use the new ports.
• BPMMigrate command can rerun if it doesn’t import SIB messages yet or you can clean SIB tables before the second run.
• Backup fileRegistry.xml if you want to enable LDAP after migration, or will meet with some errors when try to access the document tables.
• We don’t support the migration of IID UTE
43
Additional In-depth BPM Sessions• 1931 IBM BPM Upgrade and Migration Roundtable – in Coral C• Tue 9:30-10:30, • Wed 17:30-18:30, • Thu 10:30-11:30
44
Meet other clients and learn about Expert Access Services for on-demand enablement and consulting on development, migration and infrastructure topics.
Wednesday, February 25, 2PM-3PM Jasmine H, floor 3, Mandalay Bay
Please RSVP to La Donna Quinn – [email protected] show this invitation on your Smartphone at the reception entrance, or print and
bring with you to gain entrance.
Migration References• Planning a migration to the latest version of IBM BPM and IBM Business Monitorhttp://www.ibm.com/developerworks/bpm/library/techarticles/1502_sharma/1502_sharma.html
• Estimating the efforts for IBM Business Process Manager migrations –why it’s not easy!https://www.ibm.com/developerworks/community/blogs/aimsupport/entry/bpmmigrationsizing?lang=en
46
Questions?
Notices and DisclaimersCopyright © 2015 by International Business Machines Corporation (IBM). No part of this document may be reproduced or transmitted in any form without written permission from IBM.
U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM.
Information in these presentations (including information relating to products that have not yet been announced by IBM) has beenreviewed for accuracy as of the date of initial publication and could include unintentional technical or typographical errors. IBM shall have no responsibility to update this information. THIS document is distributed "AS IS" without any warranty, either express or implied. In no event shall IBM be liable for any damage arising from the use of this information, including but not limited to, loss of data, business interruption, loss of profit or loss of opportunity. IBM products and services are warranted according to the terms and conditions of the agreements under which they are provided.
Any statements regarding IBM's future direction, intent or product plans are subject to change or withdrawal without notice.
Performance data contained herein was generally obtained in a controlled, isolated environments. Customer examples are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual performance, cost, savings or other results in other operating environments may vary.
References in this document to IBM products, programs, or services does not imply that IBM intends to make such products, programs or services available in all countries in which IBM operates or does business.
Workshops, sessions and associated materials may have been prepared by independent session speakers, and do not necessarily reflect the views of IBM. All materials and discussions are provided for informational purposes only, and are neither intended to, nor shall constitute legal or other guidance or advice to any individual participant or their specific situation.
It is the customer’s responsibility to insure its own compliance with legal requirements and to obtain advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect the customer’s business and any actions the customer may need to take to comply with such laws. IBM does not provide legal advice or represent or warrant that its services or products will ensure that the customer is in compliance with any law.
Notices and Disclaimers (con’t)
Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products in connection with this publication and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. IBM does not warrant the quality of any third-party products, or the ability of any such third-party products to interoperate with IBM’s products. IBM expressly disclaims all warranties, expressed or implied, including but not limited to, the implied warranties of merchantability and fitness for a particular purpose.
The provision of the information contained herein is not intended to, and does not, grant any right or license under any IBM patents, copyrights, trademarks or other intellectual property right.
•IBM, the IBM logo, ibm.com, Bluemix, Blueworks Live, CICS, Clearcase, DOORS®, Enterprise Document Management System™, Global Business Services ®, Global Technology Services ®, Information on Demand, ILOG, Maximo®, MQIntegrator®, MQSeries®, Netcool®, OMEGAMON, OpenPower, PureAnalytics™, PureApplication®, pureCluster™, PureCoverage®, PureData®, PureExperience®, PureFlex®, pureQuery®, pureScale®, PureSystems®, QRadar®, Rational®, Rhapsody®, SoDA, SPSS, StoredIQ, Tivoli®, Trusteer®, urbancode®, Watson, WebSphere®, Worklight®, X-Force® and System z® Z/OS, are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at: www.ibm.com/legal/copytrade.shtml.
Thank YouYour Feedback is
Important!
Access the InterConnect 2015 Conference CONNECT Attendee Portal to complete your session surveys from your smartphone, laptop or conference kiosk.