Listing Variable Name : Data Item

[planoqe]

I am new to the BI Publisher tool. I am in the process of documenting forms from BI Publisher (desktop version 10.n) with our JDE 8.9 installation. I need to capture the source of each element within the form. To do so, I am pulling up each form in a fat client, selecting an element (e.g. "Sold To Line 1"), clicking into the variable properties, then manually capturing the data name. This is very time consuming. I am hoping for a more efficient method. Attached is a screenshot of the screen I am working with.

Is there a way (third party tool, coding, something in the tool itself) that will export, list, or otherwise display a complete list of the variable name : data item unions within a given form?

If more information is needed, please ask.

 

[johndanter]

Wow, that's a great question.

I would say the answer is the UBE itself and not downstream in the resulting XML as not all the UBe fileds end up in the XML if blank

The solution lay back in the UBE specs. RDASPEC RDATEXT etc

These TAM files will have the answer you're after....but they are not easy to read.

You can access these in the XREF actually. (Data Items Used By A Batch Application) Enter your UBE name. It's also locked away in F980021 (Cross Ref)

To look at the UBE specs:
Make sure your ini file is setup to have TAMMenus = SHOW and go into UTB
Top left under File click Open Local

Then open rdaspec and rdatext

Back in the rdaspec file enter your report into szReport and place a 3 into nRecordType
Click find

This is a list of all the output text that would appear on the baseline PDF. Both constants and variables

Clicking each line shows the blob info on the right hand pane. Make a note of zDbRef.szDict and idText

These can be linked back to the second file you opened, rdatext

Again place the UBE name into szReport and click find.

You'll find that idText links to this file and gives you the name of the variable.

Fun hey



Sad thing about BI development is not all the fields on the UBE are always shown in the XML output!

If the UBE has 10 fields and the data it runs over only ends up populating 8 of them, you'll only see 8 in your XML
The 2 blank fields are not displayed!!

Another way is once you have uploaded the XML into the template in MS Word you may be able export the list that appears from the insert field choices. But again, if a field is blank, you won't see it as an option.

I'll be keeping an eye on this to see what replies come out


EDIT: Sorry I just noticed you want forms
Replace all I said with fdaspec and fdatext and szApplication

 

[jileto]

I've considered the same exercise on documenting the names for BIP projects. But realized that the spec itself is already a record of the names/ids. You don't even need to read the actual spec/tam records. Just have RDA/FDA display/show the object IDs. Besides, on an upgrade, the section/object IDs may change - even on base objects. So your efforts producing the list will just be wasted because you now need to sift through the BIP templates and rename the darn things - that is based on experience.

So heed John's advice or work off the ObjectIDs from RDA and FDA. Hint... If you look closely enough, you'll figure out the naming convention used such that even if the variable is empty and doesn't show up in the XML (as John pointed out), you will be able to determine what name/tag it will end up with and just type it in BIP. All it needs if familiarity with XML naming rules and how to get the objectIDs in JDE.

But if you insist... Another way to get those specs is to save them in a PAR file - if you're using a Tools Release that supports saving specs to PAR files. Just open them with a ZIP file app or rename them with a ZIP extension. Windows will treat them as zip folders.

Then open up the RDASPEC/FDASPEC folder. There, you'll see a bunch of XMLs. You're interested in those that are named as UBENAME VERS 3.S.O.x.x.XML.

VERS is a "+" if the spec is for the base object. 3 is the record type John refers to. S is the section ID. O is the object ID.

Spend your time to come up with some sort of a parser to sift through the XMLs and generate a list. If you share it here, we'll all be eternally grateful.