http://blogs.oracle.com/xmlpublisher/2007/03/13#a192

This has the potential to be quite useful as clients frequently ask for some kind of Excel output which they then update ‘offline’ (i.e. disconnected from PeopleSoft) and then need a method of reloading the updates back into PeopleSoft.

Almost by accident while troubleshooting this issue I discovered that if I took the output text file (which incorrectly opens in the browser) within the Report Repository and editted it, then tried to open it again it would open in Excel. Strange! It seemed to make no difference what change I made – or even if I reversed out a previous change – all that mattered was that I’d editted it. Furthermore it only worked if I editted it with certain tools.

The upshot was that when you edit a text file using Windows Notepad it inserts an invisible non-printing character at the start called a BOM (Byte Order Mark). This is all related to whether the format is ANSI, or UTF-8 etc. Using a fuller-featured editor (I used Notepad++, see the Applications tab above for more) I toggled whether the BOM is present or not and this affected whether the file opened in Excel or a browser. Further testing seemed to show that it didn’t have to be a BOM character, as long as I didn’t interfere with the tags or their data content this workaround still worked.

Now although I have a method, I can’t decide the best method of implementing it. The method I use at the moment is after the file is generated – but before it is published – I insert the character. Using PeopleCode the only method I can think of to achieve this is to create a new text file, insert the character to ensure Excel output, then copy in the contents of the original output file. The only alternatives I can think of involve external calls from PeopleCode.

Any smarter ideas?

The first portion of the presentation is more of an introduction so will be familiar to many of you, from slide 32 onwards however it got more interesting.

• XBRL Publisher?
• Excel Templates (finally!)
• Master Templating (like the slide master in Powerpoint, or CSS in HTML)

The presentation can be found on Tim’s post here:

http://blogs.oracle.com/xmlpublisher/2008/04/17#a930

I’ve written an XML Publisher report that outputs an Excel file. When I open the output from within Report Manager it opens the file in the browser, when I want it opening in Excel.

I’m aware that XMLP doesn’t output binary .XLS files, but what’s described as Excel(HTML) – which is basically a text file containing HTML that can be read and rendered as a spreadsheet when opened with Excel. The file in the report repository has an xls extension, and the Report Manager Hyperlink points to the right place. If – instead of opening the file – I save it locally then open it with Excel it renders perfectly.

Also, if I change the output to RTF instead of XLS then it opens in Word correctly. It’s also not a template issue as if I preview the output from within the XMLP Report Definition it opens in Excel. This happens on more than one client PC, and in different browsers so it doesn’t look like it’s a local machine configuration issue.

If I place the output xls file on the web server and create a hyperlink on a PIA page it works fine. However if I repoint the hyperlink to the same output file in the report repository it doesn’t work – so it seems as though the psreports servlet might be the issue. If I use a tool to examine the HTTP Header for each of these requests I can see that the Mime Type is set to “Application/MSExcel” for a PIA page hyperlink (which works), and “text/html” for the same file from the Report Repository. The mime types are set correctly (by default) in the Web Server profile, but I can’t see anywhere to set the mime-types for psreports.

I’ve been in dialogue with GSC for the last 6 weeks or so, but they say that it isn’t a misconfiguration or bug, but a ‘”potential future development with a status of ‘Awaiting review’.” The case id is:

1750412000 – “8.50: Support MHTML Excel format in XML Publisher”.

It seems Oracle eBiz suite has the same issue, but they can fix it with a configuration change.

I do have a workaround (not a solution) for this – posted here – but has anyone else faced this issue? And if so, how have you dealt with it?

Another method exists however …

and that is to create a query containing a union. This way you can have your seperate rowsets either side of the union, and just add a field at the beginning to enable the template to ascertain which section of the rowset it is dealing with – I refer to this field below as ‘section field’. (You may also have to pad each side with some empty fields to ensure that the columns in both sections match up.)

Once you have your data outputting, your template can now be designed. Lay out the content, and where you want to display only data from a particular half of your rowset, wrap it in a ‘for-each-group’ with a criteria specifying your section type:

<?for-each-group:row[<section_field>='<value>'];
./<section_field>?>

for example, mine was:

<?for-each-group:row[A.EP_SECTION_TYPE='Section'];
./A.EP_SECTION_TYPE?>

and add a corresponding ‘<?end for-each-group?>’ after your content.

Before you can preview effectively you may have to edit the sample XML a little as the sample data generated by Query isn’t that good. You’ll probably want to manually edit it so that you get at least one row from each side of your union coming through.

You can of course expand this further and have many more than 2 sections split by a single union. You can have as many unions as you like, although this will make the Query a little unwieldy (alternatively place all your SQL into a single view and base your query on that).

Finally, I had a problem with one of my reports that I needed to union together when the sql contained Long fields. As I’m sure you’re aware, union statements don’t work with long fields, you have to use a UNION ALL, and PSQuery doesn’t – as far as I could find – allow a way of incorporating a UNION ALL. In the end I had to create a View containing the UNION ALL to base my query upon.

If you have problems getting your XMLP reports to work, I’ve found this is the best place to ask:
http://forums.oracle.com/forums/forum.jspa?forumID=245&start=0

It turns out that the XML Publisher default PDF output font does not include a glyph to represent a checkbox and this is an issue faced by one or two Oracle people already (Tim Dexter has written about it here). I thought I add a quick write-up as I’m tackling the issue from a PeopleSoft perspective.

Recap

Firstly, a quick recap for those who haven’t used checkboxes before in XMLP. You output your XML in the usual fashion and for your checkbox have the process spit out a single field (in most cases I’d guess this would be a ‘Y’ or ‘N’ value, but I’ve used it a couple of times where you have 5 or 6 checkboxes depending upon a single value). Then, from within Word, open the Form toolbar and insert as many checkboxes as you need. Go into the properties of your checkbox, press the ‘Add Help Text’ button and choose ‘Type your own’. In the freetext field enter:

<?fld_YES_NO1='Y'?>

replacing the ‘fld_YES_NO1’ with the name of the XML element/field you’re basing it’s state on and the Y with the value you wish the box to be checked for.

Now if you print this, there’s a good chance you’ll get the small diamonds I had instead of the ‘standard’ checkboxes we’re all used to.

So, how to fix it?

First, have a look through the symbols found under “insert symbol” in Word and choose the checked and unchecked symbols that you want to use. Make a note of the font and character code. Wingdings 168, 253 and 254, plus Wingdings2 81-84 and 163 are a good place to start.

What I couldn’t get to work

The documentation seems to suggest that you can update xdo.cfg to specify the settings for all domains and XMLP reports. Using Notepad, create an xdo.cfg file. You can find a full description of the contents in Chapter 10 of the user guide but the file I used was thus (with the bits you’ll need to change in red):

<config version="1.0.0" xmlns="http://xmlns.oracle.com/oxp/config/">
   <properties>
      <property name="rtf-checkbox-glyph">Wingdings2;84;163</property>
   </properties>
   <fonts>
      <font family="Wingdings2" style="normal" weight="normal">
         <truetype path="c:\windows\fonts\wingdng2.ttf"/>
      </font>
   </fonts>
</config>

The first red section contains the font name, the checked character code and the unchecked character code. Place this file under:
C:\Program Files\Oracle\XML Publisher Desktop\Template Builder for Word\config\ (or wherever you installed XMLP)

Now go and preview your document from within Word. If you’ve got the above correct you should see your desired checkboxes.

Testing in the PIA

If you have a data source and report definition set up already, you can upload your template and place the xdo.cfg file in the <ps_home>\appserv directory. You don’t need to reboot the App Servers when you update this file. You can then use the preview from within Report Definition > Template tab to view the results. Your checkboxes should also be correct at this point, if not, check your template and xdo.cfg file.

Now, how do we get these on the Process Scheduler?

The documentation suggests that it’ll just work from here without changes to the contents or location of the xdo.cfg file. Unfortunately running the report within the Process Scheduler still returned the wrong checkboxes.

Workaround

The workaround that I used was to specify the desired settings on a per document basis.

Go into the template document properties within Word and then the custom tab. Enter the following two settings:

Name: xdo-font.<fontname>.normal.normal
Type: Text
Value: truetype.<path to font file>
Example: truetype./appl/psoft/pshcm/WINGDNG2.TTF

Name: rtf-checkbox-glyph
Type: Text
Value: <font_name>;<checked symbol>;<unchecked symbol>
Example: Wingdings 2;84;163

The font name can be anything you like, it doesn’t have to be the name of the actual font you are using. Just make sure that the fontnames in the two properties match.

This worked in both the preview from the XMLP Report Definition and via the Process Scheduler. The only downsides are you’d have to apply these properties to each report that you need to use checkboxes in, and if you need to move your fonts then you’ll have to update every report that contains it.

Useful Documentation

The XMLP for PeopleSoft PeopleBook (in PDF format) and the Oracle XML Publisher Core Components Guide can be found here.

Find the Tools library that matches the version you’re using, and drill into that to find the individual guides.

Doing a bit of digging there are a number of suggestions, none of them relate to the PeopleSoft implementation of XMLP however so I’m unconvinced by any solution in particular.

There’s a Tools patch out for this issue (8.48.06 and up contains the fix), so check your version of Tools:
http://www.peoplesoft.com/psp/portprd/CUSTOMER/CRM/c/C1C_MENU.C1_SOLN_SUMMARY.GBL?page=C1_SOLN_SUMMARY&SETID=SHARE&SOLUTION_ID=201046967

There’s a suggestion to change a parameter for XMLP (I guess this would be on the Process Defn or more likely the Process Type in PeopleSoft):
http://forums.oracle.com/forums/thread.jspa?threadID=568832&tstart=0&messageID=2116283

There’s a suggestion to create a config file (it is not delivered) to specify a temporary directory for processing large files:
http://asun.ifmo.ru/docs/XMLP/help/en_US/htmfiles/B25951_01/T421739T422152.htm

And there’s also a suggestion that a patch will fix it:
http://www.oracle.com/technology/products/xml-publisher/docs/AboutXMLP562.htm

If I was troubleshooting it and was already on 8.48.06 or greater, I’d probably try the parameter followed by the config file.

If anyone has encountered this error and fixed it, it’d be great if you posted a comment to let us know the resolution.