All ideas are welcome. Just because the Idea doesn't make it into the product immediately does not make it a bad idea.
For every table we’re migrating, we always build the source table data on key fields, then by applying criteria in Design we can add as many zLegacyFields as needed.
When Design adds these fields, they’re usually automated into the >10k range, keeping the field order sequence +10k. All this is perfectly fine and is clear in MAP.
However, AutoGen transforms mapped data and all these fields now appear at the base of the transform list. While it’s not a huge task to move their priorities up, for a table like MARC where you may have 200 total rules in the source table, it’s not always ideal either. In my experience, most fields that require a zLegacy equivalent that are anything other than default (and if so, why do you need a zLegacy?) tend to use the zLegacy value to drive the rule (e.g. an x-ref).
The proposal is two-fold
1) instead of transform adding rules as 1>10, 200>2000 ,etc... make 1>15, 2>25, 3>35. I.e. automatically (fieldnumberx10)+5
2)zLegacy fields can then be inserted as (fieldnumber-100000) which has the effect of positioning the zLegacyField a count of 5 above the zField in the transform rule list.
e.g.
Design:
Field #1 has a zlegacy field required. Upon sync to MAP, field #10010 is appended to the table in Design.
Map:
Field 1 shows as priority 10.
Field 10010 shows as priority 100100.
AG>Transform (current) will create a transform list that matches MAP.
New Transform:
Field 1 > Priority 15
zLegacyField1 > Priority 10
No more sorting required. The secondary advantage is that this sort of sequencing does not have to be re-done each time at wave-copy. I have to redo all the priorites in multiple objects & multiple waves at the current client, this sort of automation would make wave copies much easier, while retaining all the same functionality as present today.
Guest
