Hi All,

I have noticed the following problem with XML output in BaanIV.
What I would like to do is reformatting an XML-file directly after printing.

If you setup a printer with Device Type rewrite file and Argument XML, to get report output in XML-format, only the standard conversion programm ttstpconv seems to be allowed. I tried another conversion script of my own (format otccom...), but this seems to be ignored.

Did someone notice the same problem?
Any work arounds or ideas?

Thanks for any help,
Frank

You should be able to write your own conversion script. We use one ourself. See the attached.

Mark

Hi Mark,

May be I did not describe the problem well enough.

The problem is that as soon you use XML in the argument field (instead of ASCII, as in your example), then custom conversion scripts like you mentioned are not excecuted! They are completely ignored.

I tried one thing: removing XML from the argument field, leaving my custom script, and then starting ttstpconv in my custom conversion script with XML as the third input parameter. Unfortunately, however, this does not work either (Baan gives an error message).

It looks like SSA is trying to prevent other companies to get creative here...

Cheers,
Frank

I do not think you have to include XML in the argument field. In effect you could leave it blank. If you use ttstpconv inside the script you can always hard code the XML - I think. Not sure why I included it on mine - I know this one would always be ascii when I can ttstpconv in the script. I changed mine from ASCII to XML and started getting errors before the script came up. Maybe if you just leave the argument empty it will solve your problem.

Mark

Hi Mark,

If I leave the argument field blank, I get normal report output, not the xml report output that I want.

I am trying to use the standard xml output format that you get in BaanERP when you use a device with the checkbox "Output in XML format" on.
Are you familiar with this?

Cheers,
Frank

No I am sorry I am not familiar with that. What I do in my conversion script is this:

| Arguments are passed from Baan spooler as follows:
| 1 = Name of input (temporary) file contain dev independent report
| 2 = Name of output file
| 3 = Additional arguments (from Device data)
| 4 = Specilar parm for ttstpconv (unknown reason)
wait.and.activate("ttstpconv", argv$(1), tmp.file, argv$(3),argv$(4))
[... do other stuff to launch excel with a macro...]

I was just wondering if you could leave the argument blank and run ttstpconv yourself with XML as the argument. I did a quick test on my system and I hard coded ASCII in the argv$(3) parameter. I do not really see that check box on my 4c4 system.

Mark

Hi Mark,

I tried your solution before today, and on my system I got an error message like "Conversion to XML not implemented" (or something similar).

It would be interesting to know if this works in your environment.

Thanks and cheers,
Frank

When I get sometime tomorrow I will drop XML into the code and see what happens in the output temp file. Will post after I attempt this.

Mark

I had noticed this variable some time back . May be checking this variable in program script help u.

Well gave it a quick try, but I get XML conversion not yet supported. I thought it was supported for 4c4, guess I was wrong. See the attached.

Mark

I am very new to using XML and just downloaded information from Baan Support solution 148092. I don't know if it will provide any good information to you or not, but it may be worth a look.

Hi all,

Apparently the boolean variable spool.xml determines whether a report is generated in normal output format (false), or in xml format (true).

I guess this variable can be usefull if you always want to print a report in xml-format, no matter what the device settings are. You could set spool.xml to true in the before.program-section of the report script or somewhere in the program script.

Setting spool.xml to true in a report conversion script like ttstpconv has no effect, because this conversion script is executed after the (first, non-text) report output file is generated. By then it is to late.

So for my problem, this variable unfortunately does not do the trick...

Frank

As far as I know, these functions can be used if you want to work with XML-structures in Baan 4GL (read/write/edit).

Frank

Hi Mark,

If I put things together, my conclusion is the following:

If you print a report, usually you have 2 steps:
- Step 1 where the first, non-text version of the report output is generated
- Step 2 where this file is (slightly) converted to text format (by ttstpconv)
Step 2 does not do very much, it merely removes or replaces some special characters.

BaanIV can generate report output in XML-format during the first step (i.e. spool.xml = true or argument=xml).

However, if you generate a normal (non-xml/non-text) output file during this first step (i.e. spool.xml = false or argument<>xml), you cannot convert it to xml in the second step with the standard text conversion script ttstpconv.

In fact, this is logical, isn't it?
Only during step 1 Baan goes through all the layout information that it stores in the xml format...

Cheers,
Frank

Yes - I agree. I know see what you are saying. All along I though XML was a parameter to ttstpconv, but it is separate.

So back to your problem - After the report is converted to XML you then want to run a second conversion program to add or modify what was created from the XML conversion, correct?

Mark

Yes.

The only solution that I see at the moment, is to write a separate program for the conversion of the xml file.
This program should check if an xml-output file is there in the tmp-directory (e.g. recognizable by some fix name), and then process it. This program should constantly run in a job.

Frank

I do not know if you have already solved this issue some other way but I was also struggling with this problem and after a quite a while of debugging here is how it goes:

(Std-report) generated report script calls function in r_bic_repgen_init() from 'bic_repgen'. This function obviously examines the device settings and if and only if the argument for the conversion program is XML it returns sets the variable spool.xml = true. Routine in the report script checks if spool.xml is true and if it is it calls for the functions to format the report into XML.

All this happens in the std-report way before the conversion program and as you say before, if XML argument is given in the device settings conversion program is ignored.

I solved this simply by redefining spool.xml to something which is always true in the report script with a macro (note, it doesn't help to set the value of variable spool.xml to true in the report script because r_bic_repgen_init() will anyhow overwrite it in the very beginning).

By redifining spool.xml eg. to 1 = 1 XML-generating functions are always called and still the non-std-conversion program is executed.



#define spool.xml 1 = 1 | Something which is always true

|--> in generated report script

function main()
{
r_general_initialisations()
if spool.xml then | redifinition causes this
r.xml.header() | to be executed always
endif
...

}