[sims] CLR /Params String

[pubgrub277]

i Know a few people have been looking at CommandLineReporter for a while and ive had a lot of success automating my reports using the /pramdef and /paramfile switches in my coding.

 

if im understanding this correctley though i should be able to use /params:"ABCD" (from the help file in cmd) to supply the code directly in my script rather than having to refer to another file.

 

"ABCD" is a string containing xml which defines the parameters for the report.

See the thrid party access to the sims.net SDK for details on the format of this Xml string.

 

Does anyone know this format? Do i need to buy into the SDK to use a string as opposed to using a paramfile?

 

The functionality of using commandlinereporter is the same, just a little easier if i can use a string instead of having to prep a file before running the rest of my code.

[pubgrub277]

I've managed to generate a couple of error messages whilst trying various strings of data.

 

/params:"2011-11-29T13:39:042011-12-01T13:39:04"

Gives me

there are multiple root elements. Line1,Position36.

error processing report parameters

If i use the whole of the parameters text from the pramadef file i've generate

DateDateRangeDate is between2011-11-01T13:39:042011-12-01T13:39:04

i get

unexpected end tag. line1, position 3.

[LosOjos]

You need to bare in mind that passing a string at command line means you'll need to be careful where you put quotes as the command line will assume that any quotes define the start and end of a string unless you 'escape' them properly. An easier method is to use a single apostrophe (') rather than double quotes (") anywhere you see them in the original PARAMDEF; these still conform to XML and so will still work, i.e.

 

would become

 

Also, you still need to include all of the XML tags; I notice in your first example you aren't including the and opening and closing tags for example

 

Also, the schema is not essential so you can drop it if you like.

 

EDIT: just to give a working example from your own code sample, try this:

 

Your sample:
DateDateRangeDate is between2011-11-01T13:39:042011-12-01T13:39:04

Should read:
DateDateRangeDate is between2011-11-01T13:39:042011-12-01T13:39:04

 

The error you were getting (unexpected closing tag error) was because you were including , which is the closing tag for the XML schema which you haven't included so CLR correctly reports an unexpected closing tag

Edited December 2, 2011 by LosOjos

[pubgrub277]

/params:"2011-12-01T00:00:002011-12-02T00:00:00"

 

This runs, give no errors but seems to ignore the report filter. I checked this by amending the dates in the code and the report output is always the same.

[LosOjos]

/params:"2011-12-01T00:00:002011-12-02T00:00:00"

 

This runs, give no errors but seems to ignore the report filter. I checked this by amending the dates in the code and the report output is always the same.

 

It's because you're missing essential tags; it's technically correct as the XML validates, but SIMS won't read it as it's missing tags. Change it to this:

 

/params:"[b][/b]2011-12-01T00:00:002011-12-02T00:00:00[b][/b]"

[pubgrub277]

Thanks LosOjos.

The first one was a misscopy&paste. with the schema tag.

 

Your correct about the quotes and im now getting different files now when using you suggested code.

DateDateRangeDate is between2011-11-01T13:39:042011-12-01T13:39:04

 

at least now i can skip having to prepare a /paramafile when automating the report and pass the values direct to the script.

 

Thanks for you help. Much appreciated.

[LosOjos]

You may be on to a non starter here anyway to be honest. Try my suggestion and let me know if it works please

 

The reason I say this is that when you change the date range in SIMS, the parameter ID changes in the paramdef. I've not had this confirmed by Capita (waiting more information from @David_Grashoff as we speak) but I suspect that the ID has to be changed programatically for date filters to work as any I have tried have simply returned the pre-set dates from the original report in SIMS

Edited December 2, 2011 by LosOjos

[pubgrub277]

sorry i was busy posting/working both times when you replied. i have seen you excellent correction and understand what i need. Many thanks

again

[pubgrub277]

You may be on to a non starter here anyway to be honest. Try my suggestion and let me know if it works please

 

The reason I say this is that when you change the date range in SIMS, the parameter ID changes in the paramdef. I've not had this confirmed by Capita (waiting more information from @david_Grasshoff as we speak) but I suspect that the ID has to be changed programatically for date filters to work as any I have tried have simply returned the pre-set dates from the original report in SIMS

 

 

No it works perfectly. changing the date manually in a .bat file at the moment but am scripting something else to amend how that runs.

I don't plan on amending the report in sims only using the scripts to export the data.

[LosOjos]

No it works perfectly. changing the date manually in a .bat file at the moment but am scripting something else to amend how that runs.

I don't plan on amending the report in sims only using the scripts to export the data.

 

Mind if I ask which field it is you're filtering in SIMS? I've tried this with attendance dates and it only ever runs the dates I originally set in SIMS...

[pubgrub277]

Mind if I ask which field it is you're filtering in SIMS? I've tried this with attendance dates and it only ever runs the dates I originally set in SIMS...

I'm running a report on Behaviour records. The filter is for records between dates, hence start and end date.

Is your report in another thread on here? i seem to remember reading it earlier for weekly attendance?

can't see why it wouldn't work in the same vein as this.

[LosOjos]

It's on here somewhere (struggling to find the thread at the moment) and you're right, it should theoretically work as it's just a date range the same as your behaviour one. I'm increasingly suspecting there are a few compatibility issues between CLR and SIMS but proving it is nigh on impossible... I sent my files over to @David_Grashoff a couple of weeks back to take a look so hopefully I'll hear something back soon...

[vikpaw]

I'm sure we discovered an issue on here with certain types of date field, especially, using Date Between, in certain areas of SIMS. Yet in other areas it purports to work. I could have sworn you were involved in that thread @LosOjos

[vikpaw]

Got it : http://www.edugeek.net/forums/mis-systems/82481-commandreporter-param-files-parameter-ids.html#post743725

[LosOjos]

Right, an update for you all:

 

emails have been going back and forth between myself and a very helpful member of the SIMS Partner Support team for the past week or so and finally I have it working - although I'm afraid the solution doesn't really answer what the problem is in the first place!

 

I have found that no matter what I do, passing date parameters on the command line with the CLR "/params" argument does not work. It fails for me every single time. However, if instead of outputting the parameters to the command line, I output the exact same parameters to an XML document and pass that file's name as an argument with the CLR "/paramfile" option, it works.

 

Whether this is a CLR bug or some oddity introduced by passing such a long string at the command line I do not know (but have offered to do some more testing on the matter if it will help).

 

In the meantime though, I recommend that anybody using CLR uses XML files and "/paramfile" as using the "/params" option seems unstable.

[matt40k]

I think DOS is limited to 1023 characters or something.

[LosOjos]

I think DOS is limited to 1023 characters or something.

 

See my initial thought was that perhaps it was a character limit causing the problem, however if this was the case I would not expect any of the filters to have worked, as the incomplete XML would be invalid, whereas what I actually got was that my "effective date" and "year group" filters worked but the "date range" never did. Very odd...

[matt40k]

Mmm... depends how clever Windows is at invalid XML I guess, quick check would be to re-arrange it. Personally I would prefer referencing an .XML file.

[LosOjos]

Mmm... depends how clever Windows is at invalid XML I guess

 

Not at all - XML passed as a string to CLR means nothing to Windows, it's just a command line argument...

 

Personally I would prefer referencing an .XML file

 

For me the benefit of not having to write to a file to create an XML to reference is that it removes any possible errors in my program caused by permissions restrictions for the user

[matt40k]

You would write it to a temp folder or somewhere they can - OK, you still could get disc errors, but if they only have a few MB left, they'll have problems anyway. Bonus of having a physical XML is that you have something to debug.

[LosOjos]

You would write it to a temp folder or somewhere they can - OK, you still could get disc errors, but if they only have a few MB left, they'll have problems anyway. Bonus of having a physical XML is that you have something to debug.

 

OK what I'm getting at is that it's fine if you know the network of your user and know what permissions they have, but if for instance I shared the program with you I couldn't possibly know what read/write access you have. I could give the option to change the temporary file location of course, but it would all be a lot simpler and easier if I didn't have to write temp files in the first place; that's all I'm saying

 

I had to add a "debug" mode in to the program anyway to make sure the XML was being formatted properly

 

It's no major issue, I'm just saying it's easier from a developer's point of view if you can remove the need for temp files

 

EDIT: just to add, I've no intention of selling off this program I'm just discussing the workings of CLR in the interest of the community - the more of us that know how to use it the more chance we have of manipulating the data the way we want it!

Edited December 12, 2011 by LosOjos

[vikpaw]

Is it just the date range as we found before? Can you rejig the report to utilise date before and date after, although complex, i'm sure this worked for that guy in the other thread.

[matt40k]

EDIT: just to add, I've no intention of selling off this program I'm just discussing the workings of CLR in the interest of the community - the more of us that know how to use it the more chance we have of manipulating the data the way we want it!

 

It's always good to think what if others use it, after all, at somepoint your going to refresh most of your network. So what language is your program written?

[LosOjos]

Is it just the date range as we found before? Can you rejig the report to utilise date before and date after, although complex, i'm sure this worked for that guy in the other thread.

 

I haven't tried that Vik - definitely worth a go though! At least that way we can narrow it down a bit... I do have plans to incorporate conduct points in to the report which I will also use a Date Range for so I'll see then whether it's specifically attendance that has problems or the Date Range field itself. I'll have a play over Christmas break.

 

It's always good to think what if others use it, after all, at somepoint your going to refresh most of your network. So what language is your program written?

 

It's written in C#.net - not pretty I know but it cuts development time down to nothing! Took me a morning to write the main part of the program and create the GUI, then 6 weeks debugging this problem! lol. Admittedly I didn't touch it again until I heard from Capita though.