Upgrade of Clientcode to Apps8

admin

Upgrade of Clientcode to Apps8Introduction

This wiki describes upgrade of client customizations done in Centura (7.5 or earlier) or Application Forms (on 7.5) to Application Forms for IFS Applications 8 (Apps8). It is assumed that the reader has basic Centura, porting and application forms development skills.

AQS Requirement

The AQS rule: It is an absolute requirement that each individual client customization can be uniquely identified in the code after an upgrade to IFS Applications 8.

Tool based upgrade

In this section we discuss high level how client customizations can be lifted to Apps 8 using regular tool support. This will create an understanding of required steps and complexity of the process.
Centura Customizations
To turn customized Centura code into APF code we must use porting. Porting is only available on 7.5 Service Packs 5, 6 and 7. If your Centura code is on an earlier version than this you must do a standard upgrade - customization by customization - preferably to 7.5 SP7 as porting is more stable on later service packs. If your Centura code is on SP5 or 6 then this standard upgrade to SP7 is not required.
Each Centura customization upgraded can then be ported to APF as described in the Porting Projects wiki.
After porting you will have an APF customization on Apps 7.5.

While we have no choice for the client code, we cannot recommend anyone to spend time to lift customized server code to the intermediate Apps7.5 SP567 version. This means that it will not be possible to test the upgraded Centura code and it will not be possible to test the application forms code after porting. It could obviously be beneficial to detect problems as early in the process as possible, but with the extra upgrade and environment cost one can probably motivate that we postpone verification and bugfixing until we have reached Apps8 format.
APF Customizations on 7.5
The APF framework for Apps8, including all core APF code, has gone through many major improvements:

• .net 4
• Visual Studio 2010
• New ppj framework (for .net 4)
• and multiple other improvements to remove Centura dependency and general cleanup.
  

Because of this it is not possible to extract differences on 7.5 of APF and merge them to version 8 of APF directly. The APF code on 7.5 format must be converted to Apps 8 APF format using the toolkit from R&D:

• Ifs.Fnd.SearchAndReplace.exe.
• Named Menu Conversion
• Localizable Property
• ComponentXmlExtractor
  

The toolkit is available on Apps8 Tool Disks and will be discussed later in this wiki.
In order to uniquely identify a Customization on Apps8 APF format we must convert two versions of the 7.5 code, one version with and one version immediately before applying the customization, so that we can extract the differences and apply them to the Customers Apps 8 solution. (When doing "prepare to port" from Solution Developer a copy of the assembly is made. This copy is the assembly prior to porting with new Centura customization and can be used for the Base assembly porting).

The conversion-extract-apply process will have to be run per assembly that is customized. Remember that a full Customization may have changed more than one assembly.

AQS Recommendations

The above process has many steps, many iterations and is generally error prone. A ported assembly may not work/compile without manual hands on. If it does not compile some of the conversion steps will not work and after conversion the diff-deltas in C# can sometimes be huge and complex compared to the deltas we are used to from Centura and PL/SQL.
The AQS recommendation is therefore to reimplement your client Customizations in Apps8.
For smaller projects with few or small customizations a reimplementation strategy may not be a big deal, but if you have many and/or large Customizations the reimplementation cost will of course be hard to sell the Customer or finance internally. For these Customers we believe that we can save reimplementation time by using a simplified process to create an Apps8 format sample version that can be used to copy and paste complex code sections.

The idea is that we (as necessary) lift all Centura code, then port all affected assemblies and finally convert them into Apps8 APF format. This can be done for a single customization or as a bulk upgrade meaning that we lift, port and convert all Customizations at the same time. A bulk strategy will reduce the number of times we port and convert each assembly. The simplified process will create APF code on Apps8 format, but the customizations will not be possible to identify individually using diff/merge tools. The code can however serve as a sample during reimplementation, for copy and paste into the Customer solution, and thus hopefully significantly reduce reimplementation time.

  

Upgrade Tips & Tricks

This section describes the AQS recommended strategy.
Setup project
Unless your starting version is 7.5 with APF, and does not need to be ported, you will have 3 versions and belonging project environments to consider:

• Starting version
• Intermediate version on 7.5 SP5..7 for porting
• Target Apps8 version
  

Starting and Target versions will have normal project environments ordered from CoS and setup according to standards.
The intermediate version however is different as there is no need for a complete project environment. It is only needed for porting of Centura to APF. We shall not spend time on upgrading other technologies to the intermediate version. This means that we will not need a database or an Application Server. As mentioned earlier, this means that it will not be possible to test the upgraded Centura code and it will not be possible to test the application forms code after porting.
When we port we need a project_root folder, which normally is located on the VM. For the intermediate version we shall instead use the project_roots that come with the tool disks, for example if your tool disk version is 75_SP7D then your project_root can be set to file://corpnet/files/F1Tools/75_SP7D/project_root. This way we can also skip the VM's for the intermediate versions.
As we will not document customizations and deliveries etc. in LCS for the intermediate version we will NOT setup a LCS Customization Project.
To share centura libraries in normal customization development we have a dev/clientbuild folder of the AQS Project Folder Structure. We will not have an AQS Project Folder structure for the intermediate project - instead we will use the dev/clientbuild folder available in the target Apps8 project folder. For Apps 8 projects the Centuras folders are removed, but dev/clientbuild is kept for the upgrade purpose.
The only remaining need is then a Harvest environment. This can be ordered from CoS.
CoS will setup a Harvest environment using the existing naming standard <CustomerName>_<ProjectId> + a suffix "_INTM", for example: SemcoMaritime_SEMCOAPPS8_INTM.
To register ownership of intermediate environments CoS will also create a Secured Information record "Intermediate Harvest" on the Apps8 Customization Project. The secured information will identify broker, envobjid and harvest environment name for the intermediate Harvest Environment. There is no need for consulting to ever create, edit or remove these secured information records.
Finally, developers must setup a local development environment for the intermediate 7.5 version (where we will port) as well as for the Apps8 version (where we will reimplement customizations). The 7.5 version will, as described above, use the project_root available in the tool disk. The Apps8 will use the normal project_root setup on the VM for the Apps8 project.
Observe that your R:\ drive must be mapped to the 7.5 tool disk so that the IcePorter tool is available for porting.
Centura upgrade
The Centura upgrade will be done as a regular upgrade using regular tools as described in IFS Solution Developer - Merge Code (Patch or Customization). Even though the approach will work for SP 5 and SP 6 we suggest you upgrade to 7.5 Service Pack 7. (The latest SP when this is written). The main reason is that the latest SP is more stable when you port the code to C#.
For Solution Developer to work the project need to setup a .cif file - which also identifies the harvest environment used for the lifted Centura files - the intermediate harvest environment described above. A sample cif file can be downloaded here (RMB / Save Target As). You must edit some parameters to use your own harvest and project folder:
ProjectFolderPath=\\Path\to\Apps 8 project\folder
HarvestBroker= intermediate harvest brokername
BrokerVer=7
HarvestEnvObjid=intermediate harvest environment envobjid
HarvestEnvironment=intermediate harvest Environment Name
As mentioned a couple of times, you will not have a database to use for testing your upgraded Centura code, but make sure your Centura code compiles - postpone unit testing efforts until the reimplementation in Apps8 is completed.
After lifting Centura files you should copy changed centura libraries to your "dev/clientbuild" folder in your Apps8 AQS project folder structure and check the files into the intermediate Harvest environment.
Port
The wiki Porting Projects tells you everything you need to know about porting.
Porting Issue 1: There is no database for the intermediate client version and we cannot test ported assemblies. You should however make sure they compile. Compilable assemblies will be a requirement in conversion below.
Porting Issue 2: Since there is no database for the intermediate version you will have no database to create/generate proper SQL*Hints files. The APF code created will therefore be incomplete in this area. This will as necessary have to be manually fixed when/if we copy the code to the target customer code on Apps8. (You can in theory use your Apps 8 database to generate hints files, this will give correct hints for your custom code, but the potential mismatch between core 7.5 client and core Apps8 server can cause new challenges.)
Porting Issue 3: There is no autobuilder that will update a common project_root. This means that if you have assembly dependencies, let's say you work with PURCH, you may have to checkout and build, let's say INVENT, into your local deploy files folder before you can complete porting and test compilation of PURCH.
Note: If you experience problems with applying core snippets in core code then this can probably be ignored - you won't need the core code when you reimplement in Apps8.
C# files changed during porting should be checked into Harvest as usual. Use ISD to "refresh" your assembly so that all asembly files are again available on disk - they will be needed in conversion below.
Convert
As indicated in the tool based upgrade section earlier there are 4 steps to convert APF on 7.5 format to Apps8 format. Conversion material is available on Apps8 tool disks.

• Ifs.Fnd.SearchAndReplace.exe
  

This tool runs a series of scripts to convert the code into .net 4 / Visual Studio 2010, update to PPJ 4.0 framework and other changes and cleanups. In the consulting context - creating sample assemblies used to copy from - you do not have to follow the script order described in the R&D documentation. Select all scripts and run them all at the same time. (Tip: Click ctrl-A to select all scripts. Now click space to select/deselect all scripts).
The tool will ask for a source file structure and a target file structure. The source file structure is of course the ported code above. The target needs to be in our Apps8 project as we will work with it using Visual Studio 2010. To avoid naming conflicts it is a good idea to give the assembly-folder a ".sample" extension as shown in image below.
Remember also to set the option that copies unchanged files to the target structure.

• Named Menu Conversion
  

This step is done in Visual Studio 2010. It will turn the named menu (Centura) format context menus into command manager format used in Apps8. It is done for the whole assembly.
If you don't have any context menu funcitonality to convert to Apps8 then this step is actually not necessary.

• Localizable Property
  

This step is also done in Visual Studio 2010. It will set the localizable property on all forms in the assembly to make them translatable. (Ported code on 7.5 is not translated, it inherits Centura translations).
NB: This will not work unless your assembly compiles properly.

• ComponentXmlExtractor
  

On 7.5 a file, Component.xml, is used to register forms for security, load dynamic tabs, register homepages for Zoom etc. In Apps8 this has been changed and the registration is done in the C# code directly.
ComponentXmlExtractor is a tool that is used to extract and move information from the Component.xml file in 7.5 to the source files in Apps8.
Because of the various cross references between windows and component the entire application is required to be processed at the same time. This may of course not be very practical when lifting an individual Customization.
If you are processing a large Customization without references from other (core or custom) assemblies then this tool can of course be helpful but comes with no gurantee to do it all right. For smaller pieces and customizations F1 recommend doing this work manually. <*** link F1 window reference attributes documentation ***>.
If you have a new assembly converted from 7.5 the ComponentXmlExtractor does one more important thing. It places a reference to the assembly component in the properties/AssemblyInfo.cs file. This is required in the client translation process.

[assembly: Ifs.Fnd.Core.FndComponent("cmod")]

If you are not using ComponentXmlExtractor you must add this line manually.

You have now converted to the Apps8 format. Observe that your assembly is based on the Centura version from which you started and does not contain any functional improvements that R&D has coded directly into the Apps8 version. Your converted assemblies should only be used as samples from which you can copy relevant code sections when you reimplement customizations in Apps8.
Reimplement
All normal AQS standards must of course be followed when we customize on Apps8, also when we have created sample assemblies from which we can copy relevant code sections. The main AQS requirement is that each individual customization can be uniquely identified in LCS / Harvest after implementation.
For each of the customizations to be lifted we should now:
1. Identify the changes made in the original code.
2. From the delta/changes made you should be able to identify the part of the prepared 8.0 C# code that is relevant for the customization.
3. Manually re-implement the customization by copy/pasting as much as possible from the prepared code.
Adding forms, tables, dialogs and other top level objects that is new to the component is very easy. In this case just copy the whole files to the customer project and include them as new items in your components assembly.
For customizations that is done to existing windows we suggest that you manually add GUI elements in Visual Studio, like new fields and columns, as this is much more cumbersome to do by copy and paste of code. Note: If you create GUI elements then you should make sure to setup properties for the elements as well as wire all events. Then you can probably copy event handler implementation code.
Settings up context menus using the Command Manager editor is probably quicker to do manually than using diffmerge, but the actual contents of inquire and execute handler implementation code can be copied.
Remember:
Make use of partial classes described in APF Development - Partial Classesto separate customized source from core application to minimize core impact.
We must of course do a thorough unit test.
Do not forget translation work as well as presentation objects scanning.