Spec Merge Issues

Sebastien Leclerc

Well Known Member
Hello!

I just finished a merge of custom objects from Xe to 8.9 (SP1).

I opened up an interactive application that I picked randomly, did a Validate Event Rules and I had errors on some "IF" conditions that were not valid anymore because of error :
CER ERROR #3014 : Unknown object type

After more investigation, I found out that the criterias were columns of a table that changed (F4211) and that the business view was referencing a column that no longer exist in F4211 (CDCD).

Now that the business view is fixed (the app did not need the CDCD field), I go back to FDA and the line still comes out as an error. It is even displayed as blank, making it very difficult to map the fields again, not knowing what the original line was.

I am wondering if any of you had this type of problem after a merge in 8.9 and what solutions were used to simplify the retrofit process.

Also, is there a way to launch ER validation from outside FDA and RDA? This would help document the required retrofit needed in our numerous objects.
 
Re: Global ER Validation

Weee!

One question down.

After browsing through the header files of system\include, I found the following function:

jdeValidateERForObject

After further investigation, this function is used in B91VLDT... which is the main function of R91VLDT.

R91VLDT initiates Event Rules validation for the objects specified in the data selection. VERY HANDY when upgrading to ERP8.9.

I could do ER validation automactically for hundreds of objects in less than an hour.

The processing options are as follow:

[Path Info]
Source Path: the directory where to find specs
Destination Path: The directory where to put the resulting validation reports (one file by object, like when performing the validation from within FDA or RDA)

[Object Type]
Object Type: The object type to verify. This implies that if you want to check both APPL and UBE, you will need 2 versions. I am working on a code change to verify NER BSFN as well.

[RDB/TAM]
UseRDB(Y/N): When 'N' is specified, the specs are loaded from the actual TAM on disk. Otherwise, I am not sure, the specs must be fetched from the RDB (Relational Data Base, or Central objects).
 
Sle,

regarding upgrading custom objects the following was our practice/policy:

1. For Peoplesoft standard objects (non 55) we chose to NOT merge customizations to Apps,UBEs, and BSFNs but instead re-apply them. Our experience with the Upgrade Merge process over the years has been that this is this safest and quickest way to go - particularly since you can use ER Visual compare in 8.9 to help in the process.

2. Net new custom objects can be merged but you still need to validate and test due to issues such as database changes.

Regards,
 
Re: Global ER Validation

To get the NER BSFN to go through this report, I used the following approach:

1- Modify b91vldt.c
Change:
if( jdeStrncmp( jdeStripTrailingBlanks( lpDS->szFunctionCodeOpenSystems ), _J("APPL"), 4 ) == 0 )

to
if( (jdeStrncmp( jdeStripTrailingBlanks( lpDS->szFunctionCodeOpenSystems ), _J("APPL"), 4 ) == 0 ) ||
jdeStrncmp( jdeStripTrailingBlanks( lpDS->szFunctionCodeOpenSystems ), _J("BSFN"), 4 ) == 0 )

2- Add a version to B91VLDT with the following selection:

Object type = BSFN
Language = NER

Voilà!

Now, all of the code of our customs can be validated!
 
Back
Top