Siebel deployment is a good and easy infrastructure to manage configuration management procedure during Oracle Siebel projects

1. G E N E R A L A P P R O A C H
Siebel deployment
2/18/2015roman.agaev@zhiongroup.com

2. Current situation
 Complicated management
 Time spent on changes registering (files, systems etc…)
 Time spent on changes verifying (changes compatibility)
 Similar problems for each system in enterprise (Siebel enterprise)
 As more systems as more time consuming and complexity
 As more time consuming and complexity as more mistakes
 Mistakes equal time on recovery
 Recovery consumes time
 Not single person operation
 Not low level specialist operation
 Complicated management in distributed environments
 Version migration
 Manual work
 No server work interference ability (srf change on the fly)
 No versions for target enterprise
 Complicated/unreliable recovery/return to previous version
roman.agaev@zhiongroup.com

3. Future situation
 Environment management
 Complex environments definition
 Single point of management (start, stop, restart)
 New version deployment
 Task scheduling for daily version generation
 Zero-downtime version migration feature
 Version management
 Baseline version (full)
 One version for whole enterprise
 Approach and interface lead to process simplification
 No need for changes registering
 Reliable version migration process
 Unified log engine for the whole operation
 Fully extensible
 Workflow process and TBUI automatic activation
 Quick fixes support
 Flexible definition of objects for the quick fix
 Product migration support (in beta)
 Version migration
 Supports target system versions (snapshot)
 Supports recovery/return to previous version
 Supports zero-down time versions (not for full version)
roman.agaev@zhiongroup.com

4. Siebel deployment features
roman.agaev@zhiongroup.com

5. Enterprise management.
Is it so simple ?
2/18/2015
• To manage all the
servers from the
single point ?
• To deploy a new
version for the
overall
environment ?
roman.agaev@zhiongroup.com

6. Siebel deployment.
Enterprise management
roman.agaev@zhiongroup.com

7. Version migration
Is it so simple ?
Source Target
2/18/2015roman.agaev@zhiongroup.com

8. What about the version
snapshot protocol ?
It seems that the mechanism needs
predefined directories structure.
Is there any security issue ?
Probably yes.
It must be understood that each version migration process initiation
can possibly be wanted to be backed up. The process must allow
snapshot taking just before the new version is taking place at the
target.
2/18/2015roman.agaev@zhiongroup.com

9. What about the security ?
It must be understood that the version cannot be proceeded within
some predefined environments before administrator provides some
additional credentials.
It seems quite
important.
2/18/2015roman.agaev@zhiongroup.com

10. What about the data ?
 Repository
 Web files
 Web applications
 Configuration files
 Enterprise profiles
 Workflow processes
 Custom application entities (~ 20)
 Names server configuration file
 Database objects – views, aliases etc...
Is data of the same
type ? Probably not ...
2/18/2015roman.agaev@zhiongroup.com

11. How the data can be derived ?
 Repository
The repository is probably the simplest part of
version migration when the strong internal
mechanism promise its efficiency under some
constraints defined by its creator (imprep, exprep)
2/18/2015roman.agaev@zhiongroup.com

12. How the data can be derived ?
 Web files, Web applications, Configuration
files
The files can be taken from predefined allocations
and transferred using predefined tools to the version
directory tree
2/18/2015roman.agaev@zhiongroup.com

13. How the data can be derived ?
 Enterprise profiles, Names server
configuration file
The named subsystem can be changed or created
using alphanumeric application (srvrmgr) that
exposes additional API in order to simplify a work on
named gateway server.
The configuration file can be parsed and updated
accordingly.
2/18/2015roman.agaev@zhiongroup.com

14. How the data can be derived ?
 Database objects
In many cases environment has different objects on
database layer, such as:
 Database views
 Database functions
 Stored procedures
All of these can be transported without additional attention and
unreliable manual work.
roman.agaev@zhiongroup.com

15. How the data can be derived ?
 Custom application entities (~ 20)
The data stored in application section of database, but
directly related to the application
definition/customization/configuration
 EAI Rule Set
 EAI Lookup Map
 EAI Data Map
 List Of Values
 etc...
2/18/2015roman.agaev@zhiongroup.com

16. Derivation driver (HTML Application)
Predefined
Environment
structure
Repository
extract
Custom
Data
extract
HTML Application (HTML/CSS GUI)
WSF libraryEnviro
nment
configu
ration
definiti
on
(XML)
JS library
COM EXE JDB WMI WS
File
System
2/18/2015roman.agaev@zhiongroup.com

17. Update driver (HTML Application)
Predefined
Environment
structure
Repository
import
Custom
Data
import
HTML Application (HTML/CSS GUI)
WSF libraryEnviro
nment
configu
ration
definiti
on
(XML)
JS library
COM EXE JDB WMI WS
File
System
2/18/2015roman.agaev@zhiongroup.com

18. Siebel deployment.
Version migration (baseline) - snapshot
2/18/2015roman.agaev@zhiongroup.com

19. Siebel deployment.
Version migration (baseline) - import
2/18/2015roman.agaev@zhiongroup.com

20. Siebel deployment.
Version migration (quick fix) - snapshot
2/18/2015roman.agaev@zhiongroup.com

21. Siebel deployment.
Version migration (quick fix) - import
2/18/2015roman.agaev@zhiongroup.com

22. Siebel deployment.
Products migration - export
2/18/2015roman.agaev@zhiongroup.com

23. Siebel deployment.
Products migration - import
2/18/2015roman.agaev@zhiongroup.com

24. Siebel deployment.
Zero downtime – version deployment
2/18/2015roman.agaev@zhiongroup.com

25. Questions ?
Contact: roman.agaev@zhiongroup.com
roman.agaev@zhiongroup.com