problems writing files

[Marc Lang]

Hi,

I have a production which passes files around.

I use a generic message to do this.

/// Holds a filename and content for any document
Class GGC.Messages.GenericDocument Extends Ens.Request
{

Property Content As %GlobalBinaryStream;

Property FileName As %String(MAXLEN = 150);

}

I have a Business Operation which receives this file, and tried to write it to disk.

Class GGC.Operations.WriteSCIStoreFileNew Extends Ens.BusinessOperation [ ProcedureBlock ]
{

Parameter ADAPTER = "EnsLib.File.OutboundAdapter";

Property Adapter As EnsLib.File.OutboundAdapter;

Parameter INVOCATION = "Queue";

Method WriteGenericDocument(file As GGC.Messages.GenericDocument, Output pResponse As GGC.Messages.WriteDocumentResponse) As %Status
{

set originalSize = file.Content.Size

$$$TRACE("In WriteGenericDocument, filename is "_file.FileName_" and content size is "_originalSize)

set content = ##class(%FileBinaryStream).%New()

$$$TRACE("Copying content to new stream")

do file.Content.MoveToEnd()
set content = file.Content
do content.MoveToEnd()

$$$TRACE("New stream size is "_content.Size_". Original was "_originalSize)

// Prepare the response
set pResponse = ##class(GGC.Messages.WriteDocumentResponse).%New()
set pResponse.Success = 1 // Set to true to start with. Error would be the exception

set fileName = file.FileName
if (fileName = "")
{
Set fileName = ..Adapter.CreateTimestamp(fileName)
}

set status = ..WriteFile(content, fileName)

if ($$$ISERR(status))
{
set pResponse.Success = 0 // Set success false
set pResponse.Message = "Error writing generic document: "_$System.Status.GetErrorText(status)
quit $$$OK // Quit out
}

$$$TRACE("Clearing and killing content property")
do content.Clear()
kill content


quit status
}

Method WriteFile(fileContent As %FileBinaryStream, fileName As %String) As %Status
{
$$$TRACE("In WriteFile, filename is "_fileName)

if (fileName = "")
{
Set fileName = ..Adapter.CreateTimestamp(fileName)
}

$$$TRACE("Writing "_fileContent.Size_" bytes to disk")

   Set tStatus = ..Adapter.PutStream(fileName, fileContent) quit:$$$ISERR(tStatus) $$$EnsError("Error writing file in WriteFile: "_$$$StatusDisplayString(tStatus))

$$$TRACE("Leaving write file")

Quit tStatus
}

XData MessageMap
{
<MapItems>
<MapItem MessageType="GGC.Messages.GenericDocument"> 
<Method>WriteGenericDocument</Method>
</MapItem>
</MapItems>
}

}

This works inconsistently.

Some files that get written out (about 20%) have a size of 0k.

However, I know for a fact the files should be bigger.

When looking at the tracing, the tracing states:

In WriteGenericDocument, filename is SOAP50416128K_WIG_1009237_12000048474_4647911_401731_YR0022.xml and content size is 44449 

Copying content to new stream 

New stream size is 44449. Original was 44449 

In WriteFile, filename is SOAP50416128K_WIG_1009237_12000048474_4647911_401731_YR0022.xml 

Writing 44449 bytes to disk

Leaving write file

Clearing and killing content property 

So looks as though all the bytes are there?

Any idea what's going on?

This is with Overwrite set to "TRUE" or "FALSE", seems to make no difference.

[Marc Lang]

Ok, some further inconsistency, now it seems to be writing out 32kb files. 

Truncating at 32kb when it should be around 40k or 50k a file.

[Liston Neil (NATIONAL SERVICES SCOTLAND)]

Hi Marc

 

I would try something like this

 

set tFile = ##class(%FileBinaryStream).%New()
set tFile.Filename = file.FileName
set tStatus = tFile.CopyFromAndSave(file.Content)

 

Cheers

Neil

 

From: ensemble-in...@googlegroups.com [mailto:ensemble-in...@googlegroups.com] On Behalf Of Marc Lang
Sent: 11 October 2012 11:40
To: InterSystems: Ensemble in Healthcare
Subject: [InterSystems-EnsHlth] Re: problems writing files

 

Ok, some further inconsistency, now it seems to be writing out 32kb files. 

Truncating at 32kb when it should be around 40k or 50k a file.

On 11 October 2012 11:25, Marc Lang <marc....@gmail.com> wrote:

 

--
You received this message because you are subscribed to the Google Groups "InterSystems: Ensemble in Healthcare Community" group.
To post to this group, send email to Ensemble-in...@googlegroups.com
To unsubscribe from this group, send email to Ensemble-in-Healt...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/Ensemble-in-Healthcare?hl=en

********************************************************************************************************************

This message may contain confidential information. If you are not the intended recipient please inform the
sender that you have received the message in error before deleting it.
Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents:
to do so is strictly prohibited and may be unlawful.

Thank you for your co-operation.

NHSmail is the secure email and directory service available for all NHS staff in England and Scotland
NHSmail is approved for exchanging patient data and other sensitive information with NHSmail and GSi recipients
NHSmail provides an email address for your career in the NHS and can be accessed anywhere

********************************************************************************************************************

[Marc Lang]

Thanks Neil,

I didn't notice that existed. Will give it a go!

[Ted Peck]

Hi Marc,
A couple comments on your method -
- Extending Ens.Request is not recommended any more. It's more efficient to store different message body types each in their own table.
- Instead of writing this yourself you could use the classes Ens.StreamContainer and EnsLib.File.PassthroughOperation to streams out to files on disk.  There's nothing wrong with doing it yourself but it puts the responsibility of debugging on you instead of on us, and our support folks will need to be educated on how you've done it if you need their help.
Ted

[Marc Lang]

Hi Ted,

Thanks.

Interested in the Ens.Request thing. I had training around a year ago and that was in the materials.

I actually thought all messages HAD to inherit from Ens.Request/Ens.Reponse.

How would I go about the preferred method - what would my GenericDocument class need to inherit from or implement?

Thanks

[Lexi Hayden]

I discussed this recently with Ted and learned this:

The message class should extend %Persistent. You might also want to include

%XML.Adaptor and Ens.Util.MessageBodyMethods as superclasses. The %XML.Adaptor class provides support for displaying the message in XML form in the Management Portal. The Ens.Util.MessageBodyMethods class provides additional support for displaying and working with the message in the Management Portal.

NB: The message class does not need to include the [ ClassType=persistent ] keyword. This is implicitly included when you subclass %Persistent.

Thanks

To unsubscribe from this group, send email to Ensemble-in-Healthcare-unsub...@googlegroups.com

[Andrew Harris]

The change in Ensemble practice is news to me also. Was this in release notes?

 

(Though I was aware of the alternative below, which also allows the same message body type to be passed around as request and response.)

 

Thanks

 

Andrew

Thanks

To unsubscribe from this group, send email to Ensemble-in-Healt...@googlegroups.com

For more options, visit this group at http://groups.google.com/group/Ensemble-in-Healthcare?hl=en

 

 

--

You received this message because you are subscribed to the Google Groups "InterSystems: Ensemble in Healthcare Community" group.
To post to this group, send email to Ensemble-in...@googlegroups.com

To unsubscribe from this group, send email to Ensemble-in-Healt...@googlegroups.com

[Joshua Goldman]

Hi. I’m a new technical writer working on Ensemble.

 

Apparently this recommended practice is not new. Although you had to inherit from Ens.Request/Ens.Response, this hasn’t been true for a long time (maybe 5 years). So it doesn’t make sense to put it in the release notes as a recent change.  I’ll make sure that the current documentation doesn’t suggest this. If you know of any of our doc, training materials, or samples that include this obsolete practice, please let us know.

 

Thanks