Tuesday 4 October 2016

Building blocks–exactly what a DD is!

This is a post for all DEV and CNC people to use when deciding how they are going to change some description on a screen.  It’s important to consider the lifecycle of the change, not just the time it takes for you to hack the change into FDA.  You need to think about ESU’s, upgrades and more to ensure that you are doing the right thing and the cheapest method of making your change.

Verbatim from oracle support – “To override the data dictionary default text in the application, the following methods are available and the text override method is applied in the following order:”

And here are the handy documents and some description from me.

  1. Data Dictionary Text Change
    Review Document 626622.1 E1: DD: Data Dictionary Text Change
  2. Data Dictionary Jargon
    Review Document 626565.1 E1: DD: Data Dictionary Jargon Code
  3. Vocabulary Overrides
    Review Document 626466.1 E1: DD: Vocabulary Overrides
  4. Event Rule Code
    Review Document 865183.1 E1: DD: Override Application Text using Event Rule code

DD

  • DD Text is easy and goes everywhere that there has not been a specific override done, P92001
  • DD affects interactive and batch the same
  • Do a full package after a DD change, just to be sure.  Then you’ll know what you have to do next if some text does not change
  • If you have made a change with FDA / Jargon or Vocab overrides – this is NOT going to work!

Jargon

  • This is like an override per system code
  • So finance people call MCU Business Unit and Distribution call it warehouse, cool
  • We have a Jargon code for a task which says whether it’s 09 or 42 and we have an alternate description based upon that
  • Note that a task can have a jargon code, and a application can define it with OMW Product System Code of the Application

image

image

image

Note that the screen shot above is for the various descriptions per system code for MCU

Vocab overrides (VO)

  • first rule of vocab overrides is don’t use vocab overrides
  • The second rule of vocab overrides is don’t use vocab overrides
  • The third rule of vocab overrides is to understand them to use them properly! (thanks fightclub!)
  • Apart from changing code, this is as hard core as configuration gets. 
  • The only thing that is going to trump a VO is code change.  So – unless you are tucking into FDA and RDA – this is your last chance to get your description correct.
  • Remember that vocab overrides write DIRECTLY to central objects, no check-out needed!  WOW!
  • So you change a VO, the change is written to the F987* files for the pathcode that the project status allows you to check-in to.  There is a leap of faith there, I hope you understand what I wrote.  It does not change your local SPECS.  You need to do a get!  (When making Vocabulary Override changes in the Vocabulary Overrides application, the application updates the information in the Central Objects repository directly. The information is not updated in the local client specifications. In order to see the changes the specifications can be deployed in a package or the specifications can be refreshed on the individual local client.)
  • You should only do VO’s under the guise of OMW, as the objects will need to be promoted.
  • They are cheeky and sometimes require a bunch of builds and deploys.
  • You need a fatty for them
  • They do not survive an upgrade or ESU
  • After checking in the application, the vocabulary overrides can be verified using P9220
  • Vocabulary Overrides are stored by language:
    • in FDATEXT by Interactive Application name, TextID, Language
    • in RDATEXT By Batch Application template/version, TextID, Language
  • Below is an interesting sequence of screen shots demonstrating JDE not recognising a subsequent change to a VOCAB, a rechange / back to original messes everything up.
  • It shows that the specs on the app have the new description of “Shannon”, but the vocab overrides app thinks that it’s the first changed value – wow – what a mess.

clip_image002

If you look in UTB for local specs:

clip_image004

The id is 2088 and it’s got a value of Shannon, but if you look at vocab overrides, it’s default

clip_image006

Where is it coming from?

Delete glbltbl and dd* from spec dir – still wrong  - delete runtimecache for fdaspec in spec dir – still wrong.

Restart JDE on fatty

Still wrong locally

clip_image008

I change to Wrong Side failure (note that I cannot use the overridden DD item description, as it marks the item as not changed if I use this)

clip_image010

When I open the item, I get the standard description:

clip_image012

But, it’s been overridden in CO in PY.

No matter if I get from PY too, I still do not get the override

clip_image014

ER Code:

This one is simple, open the app and change the description.  Follow your SDLC and it’ll work like any other change.

2 comments:

TFerrara said...

Interesting, thank you

TFerrara said...

interesting, thank you