Any update on this subject is really appreciated , just want to know that if we build the ATG code which is working fine with 11.1 in 11.3 setup we will come to know about the functions/API which are depreciated and not working with 11.3? so through that way we will come to know about the change we need to make in the ATG code for 11.3 to make it work and have the build successful?
Hi User, Kindly Refer the following document.
Go through the document and come up with you queries.
~regards , ~Kavimani Gunasekaran
As far as I know you do not require any code changes for migration from 11.1 to 11.3.
First would be to upgrade the database to 11.3 then build the application with 11.3. The startup logs will throw if there are errors.
The bigger change is the Endeca migration as there is no direct way to go to 11.3. You need to migrate to Endeca 11.2 and then to Endeca 11.3
Thanks Shaik & Kavi. Yes , just by googling few links/tutorials on this i found that there is no code change required as such apart from the custom build.properties which is internal to ATG code base where you may have hardcoded the ATG installation path which needs an update from 11.1 to 11.3, etc apart from that by and large ATG code running in 11.1 should work the same post migrating to 11.3 without any major hassles.
@Shaik - When you say we need to upgrade to DB 11.3 (we are using Oracle DB 12.1 which is compatible with ATG 11.3) this is internal at ATG schemas right CAT A/B, PUB, PROD? these will be upgraded as a part of the CIM migration utility we run ? and just we need to follow the migration document of ATG 11.3 to execute the step by step process for the DB upgrade ? But i see one major change here in the migration guide for 11.3 under section 6 – Application-Specific Post-Migration Steps, there were few post migration steps mentioned,
Migrating Bi-Directional Properties – the usage of dcs_cat_chldprd table which is used for the Product Catalog and the changes associated with it.
This may require some update as i can see the sec_asset_version column is no longer needed for 11.3 and this is specific to Publishing Schema.
I mean schema upgrade to 11.3.
Yes, the schemas are upgraded as part of the CIM. You can follow step by step executing sqls as well depending upon the number of environments to upgrade and organization structure.
If there are multiple environments with separate roles then better to list sql files, install steps, configurations etc which can be handed over to different teams like DBA, System Admins etc.
Regarding the sec_asset_version column, even if it exists no harm. The column will be unused.
Thanks Shaik as always, one query here. In the migration guide for 11.3 it is mentioned as below,
Some versioned relationships can be modified so that the extra asset version column is no longer needed. These bi-directional properties are defined on two different item descriptors that reciprocate each other and are stored in a single table. For example, this could be a list of products in a category and parent categories on a product. Use of these properties requires a data migration, as there are changes to the repository definition.
Note: Not all relationships can be migrated. The property must be a LIST-SET or SET-SET many-to-many property with one of its SET sides configured for read-only (or writable="false" in the repository definition.
The following is an example of a LIST-SET property from the product catalog with the productparentCategories set to read-only.
Also it talks about migration of a table with a sec_asset_version column which is no longer used by creating a temp table. Whether those change needs to be done manually in the repository definition file? as you were telling the sec_asset_version column, even if it exists no harm. The column will be unused.
Whether this will create any issue during the application build/deployment if we leave it as it is ? also i think this should be done manually and wont be done through the CIM migration utility or DB scripts? Please clarify.
The tables can be left initially incase if you need to rollback the migration. There are no definition file changes needed for this.
Could you please let me know your input on this.
I already mentioned above, there are no code changes for the bi-directional properties.