Configuration Deployment & Application Migration FAQ
1. The new migration tool covers Repository, ADM, Runtime repository (ex srf) and files. Does this tool need a separate license?
2. Is applying patches ZERO downtime?
Patches typically make changes not only to the client framework (in the form of JS, CSS, and images), but also to the server framework (in the form of DLLs or SLs). As user sessions ultimately reside on a specific machine, replacing the server framework on the machine will result in the loss of that user session. So, IP17 doesn’t allow patches to be applied with zero downtime for every user, but by updating servers on a round-robin basis, some users can be kept online while other servers are patched. Zero downtime patching is on our roadmap for the future though.
3. If there’s no SRF where will all the caching go?
The SRF is essentially loaded into memory right now and cached there - in IP17, repository content is loaded from the database directly instead
4. Can the compile process to SRF still be followed? Or is Workspaces the only option going forward?
No SRF means no SRF - Workspaces are an enabler for composer mode and a great deal more besides, so Workspaces will be the only option going forward.
5. How do we check on logs, or change environment variables that we used to do on the development environment?
You will still need access to the host OS for some operations
6. So is DDLsync obsolete, are there any changes to tables/columns?
DDLSync is not obsolete. It has a new REST façade to allow it to be marshalled automatically as part of a migration process, but it can still be used manually at the command line if required.
7. Scenario: for some of our customers we do not have access to the customer environments and it's not possible to use the migration application. Does the Migration application allow the ability to export the package to be deployed?
Essentially the migration tool is just automating a bunch of command line tools that you're probably already familiar with - so you can continue to use those if required, they just now have REST facades :)
8. I'm scared about new crash scenarios, we have new components here: so new things that can crash.
Our new deployment components have been thoroughly tested there should be no further cause for concern here.
9. Are all the application Server Management / Configuration options still residing in the application?
Yes - for now
10. Do we have any scheduling processes for these migrations?
It won't start until you press the "Go" button.
11. So we can use CHEF for deployment on premise?
CHEF is a 3rd party tool
You would need to research to determine the applicability to your deployment.
12. Can "delivery" be scheduled to run off hours?
Delivery is not currently a scheduled process. Once delivery is processed and migration occurs, users who log out and log in will get the new configuration immediately.
Delivery into the integration or MAIN branch depends on how you have your setup, but it can be done by Approval Manager. Once the changes are reviewed/approved in Approval Manager, you can have a cron job that does the delivery on a scheduled basis.
13. Does the Migration tool support restoring to previous version of the repository or reverting back changes?
There are two options for reverting configuration. Either revert the source and re-migrate, or revert the production system to the previous version of the repository. Note that migrations often deal with more than just repository; migration tools don’t provide a way to revert data changes (such as LOV content)
14. Can we use this to migrate data from one environment to another?
Yes. This is one of the primary tasks of migration.
15. If the SRF is not necessary, are all changes deployed with zero downtime?
16. I assume that the Runtime Repository only deals with the Main branch of the application? Can repository data be specified (e.g. just Manifest, custom entries newer than date X)?
You can configure which integration repository is migrated to the production system. Runtime Repository can correspond to Main or Integration Workspace based on what you choose to migrate or deploy to production.
...So Manifest migration is fully operational for Workspaces?
Manifest in 17.0 is not Workspace enabled.
...How would you migrate just a few manifest entries?
One can transfer manifests using Data Services via INP files
17. Can Application Migration be scheduled?
There's no built in scheduling in IP2017.
18. So Siebel Approval Manager(SAM) is to be used in the lower environment like Dev and is purely a governance tool and not to be used for Migration of code to different environments?
19. What is mandatory DR?
Mandatory DR is the subset of DR that is required in Production database. Example of mandatory DR - Tables, Assignment Manager metadata, etc as they're referenced from DR.
20. Should be migrate using only this new feature or can it be done manually?
You can continue to perform migration manually if desired/required. All the migration services are REST enabled, the UI is one of the means of execution, one can execute the REST URLs independently.
21. Do we get logs for migrations for non-repository items, like what LOV's are moved to production and other things?
Yes...the log files in the Migration UI will display the count of LOVs transferred.
22. For multi-lingual deployment should one create one migration profile per each language??
No, metadata can be migrated for multiple languages together. LOVs would be migrated as part of ADM - so you would configure the data to be moved through ADM filters.
23. Do we still have SRF in 2017 ?
No, SRF is now the Runtime Repository (RR).
...Can we manually migrate the RR?
...RR is a bit misleading name because Workflow is a part of RR but it was not a part of SRF?
Workflow were dynamically deployed earlier also, now other metadata is part of RR and deployed dynamically without the SRF.
24. Does the Tool support Dev > Source control/package, and the package > target environment. We would never connect Dev to the Production environment. Otherwise something could change in the Dev end so you couldn't guarantee the same package is sent to System Test as what is sent to Production.
Yes, that is in our plans and will soon be supported.
25. Do we need to refer to column names when building expressions? do we have a data dictionary for easy reference?.
The INP & RUL file understands COL_NAMES and not logical names.
26. Are child records also deployed when selecting records in a parent table?.
To achieve, we need to use ADM rather than DB utilities (dataexp and dataimp).
...So that is just the same as the ADM projects that are based on content/integration objects.
Correct. All the ADM services are now REST enabled and can be accessed from the Migration Application
27. Is this a process that needs to be visually monitored from start to end or can you set up alerting via SMS or email?.
Visually monitoring is not required, once the execution is completed, the results move to History View and the admin can view in the History View.
...but what if there is an error encountered in the process?
It will show the migration step as an error and admin can view the Log file via the log button
28. Is it possible to make "disconnected" migration, when source and target systems could not be connected online?
Yes - but not supported with UI options (yet).
29. Currently we migrate all of our code from the Development environment to the version control software which then acts as single source for QA, Performance and Production environments. is the still possible with IP2017??
No, Workspaces serve as the version control in IP17.
30. Could you embed the "new applications" (SAM, Migration, SMC) in classic Siebel applications using Symbolic URLs (with SSO)
Yes, they're web applications .. so no reason why not.
31. Is Development to Test and Test to Production executed from the same SMA ?
SMA can be configured on a different server.
32. When this run does the target system need any downtime?
No downtime is required.
33. Will a new OEM Siebel plug-in be coming out around the same time as IP2017? Will any of this functionality be incorporated into OEM?
We are working on an OEM plugin but it will come in a 17.0 Patch Set. However, one thing to point out is that the OEM plug-in will do what SMC is doing (deployment) and later administration that is done via srvrmgr, so not what the migration application does.
34. Are joint Workspaces (for products, signals etc.) also migrated with this process?
Joint Workspaces are migrated via ADM.
35. When can users see the migrated changes if there is no down time?
Simple - log out - log in.
36. Does the Migration Application have it's own log? if yes, where would it be?
It has its own migration.log file with different log levels - applicationcontainer/logs/migration.log file
Component log files are still on the servers and in the same location as before given the tools used to do the migration are the same as before but now fronted with a user interface and executed via REST
37. Can the tasks run in parallel?
Yes, you can run migration plans in parallel.
38. How to revert or rollback the migration if it problems are observed in the target environment? Is there a way to backout the migration completely in a destination environment using this tool?
There is no automatic rollback/backout for migrated changes supported yet.
39. So all migration input is finally compiled in the File System and not in Database - right?
Yes, data that is to be migrated is exported into the File System.
40. When we start the Siebel Server Windows service, do we need to manually run SES and AI containers? (i.e. applicationcontainer\bin\startup.bat)?
Yes, we need to manually start the SES and AI tomcat....Siebel doesn't provide a service by default. However, the user can create one themselves.
41. Why do we need to clear cache manually, is clearing the cache part of the deployment plan for LOV? will the clear cache button work for just the active server you are on or all Siebel Servers in the Enterprise?
The clear cache behavior is the same as before - it applies to all Siebel Servers in the Enterprise not just the active one.
42. Will this migration folder get cleaned up periodically by itself? or will it be handled through sfscleanup?
The migration folder will be cleaned by sfscleanup.
43. Is there way to make all changes available at once? If there are dependencies between objects and user does logs back in middle of migration, will users experience unexpected results?
The User can see only if the migration of a specific resource is done, for example, once RR is migrated, the user can view the RR changes, while the business data or ADM data migration is going on. It perhaps might be recommended to advise users to log out and back into the application once a migration is complete.
44. The old ADM (server) did invoke some business services to clear the cache on the target environment. Is there a "resource" to do that?
We have a resource for clearing LOV and Workflow activation and the framework is open so you can plug in your own resource as long as that resource is exposed via REST.
45. Can the Migration Tool be used to migrate OM/Enterprise parameters?
No it cannot migrate OM/Enterprise Parameters.
46. Will the Migration Tool allow more complete rollback than just repository data?
The current roadmap includes rollback support for repository data via a “last know good version” feature concept. We are also reviewing how to enable/rollback data via Workspaces.
47. Is there a better way to migrate siebns.dat data like OM/Enterprise parameters as part of the new Workspace/Management feature?
This is being reviewed as part of enabling Siebel Management Console to support Server Management features.
48. Has migration performance improved from previous versions?
Migration principles remain the same and the processes are now automated using the same utilities that have been recommended to customers previously. Along with automating the end to end process, there are enhancements to support full and incremental migration that were not available before. e.g., SRF was a full migration earlier whereas with Runtime Repository definitions, it is incremental. So removal of manual steps, automating various processes by stitching them together to provide a seamless experience will help with overall experience and provide improvements in overall time spent for migration.
49. Are there any plans to add an OOTB build number field (as opposed to Date) to all seed data objects for easier filtering/control with ADM and tie into the overall migration package?
Not currently, we will review this requirement.
50. Earlier versions had a requisite that following a State Model migration, the Siebel Server had to be restarted - is it still applicable?
This part of the Application has not changed and still remains the same for IP17.
51. Does the Application Migration process stop if one of the steps fail?