Hi Ken

In ObjectScript an abstract class simply means that you can not instantiate it.   You MUST subclass it and instantiate the subclass.

The concept you understand is supported in Objectscript but it requires that you declare the method itself as abstract.

The two (abstract class keyword and abstract method keyword) work independently of each other.

Does this explain what you are seeing better?

Hi Yakov

First, I wouldn't implement this kind of logic in a business service.  I would have a business service that immediately passes a message to a business operation and then perform these functions there (or possibly in business operations).   Services should not be long-running which building and querying a staging table seems like it might take some time.

My stream definition is

Property Streams As list Of %CSP.CharacterStream;

I used the %CSP.CharacterStream because that is what was being created in the %request object and I figured it would be simpler to just add that stream to my collection.  

I understand why this would be stored in CacheStream as it it created by the CSP engine.   I think my solution is to use a %Stream.Character and actually copy the contents from the %CSP.CharacterStream rather than storing itself.

If it is desirable to have the customized setting heading with distinct separate words (like in the HL7FTPService) in the production configuration view then the global CacheMsg should be updated in the related namespace (e.g. Ensemble) where the production will be running as it is shown below for the RemoteArchivePath:

  Ensemble>set ^CacheMsg("EnsColumns","en","RemoteArchivePath")="Remote Archive Path"

After that change the RemoteArchivePath setting name is shown in the view as ‘Remote Archive Path’.


I had seen that in the docs and have tried various flavors of it.  I am using embedded SQL in a classmethod here to do my search.   Here's the method

ClassMethod Search(pSessionId As %String, pSearchString As %String) As %Stream.GlobalCharacter
    set tTags="<span style='background-color:yellow;'>"
    SELECT %iFind.Highlight(Text , :pSearchString , '' , :tTags) into :results 
    FROM SSA_OCR.TempSearchable)
    quit results

When I try to use this, I get:

SSA>s rs=##class(SSA.OCR.TempSearchable).Search(20, "Cough")
 quit results }
<UNDEFINED>zSearch+7^SSA.OCR.TempSearchable.1 *results
SSA 2e1>w results
W results
<UNDEFINED>^SSA.OCR.TempSearchable.1 *results
SSA 2e1>w %objlasterror
0 àŠ=<CLASS DOES NOT EXIST>zApplyTransformation+6^%iFind.Utils.1”SSAŠ*^zApplyTransformation+6^%iFind.Utils.1^15d^zPrepareTransformations+27^%iFind.Filer.Basic.1^1(d^zFileIndex+33^%iFind.Filer.Basic.1^1*d^zFileIndex+8^%iFind.Filer.Semantic.1^1*d^zFileIndex+5^%iFind.Filer.Analytic.1^1"d^zHighlight+17^%iFind.Utils.1^1,e^%0JmCm3l4tudf^SSA.OCR.TempSearchable.1^41e^%0JmBuncommitted+1^SSA.OCR.TempSearchable.1^1(d^zSearch+6^SSA.OCR.TempSearchable.1^1e^^^0
SSA 2e1>d $System.OBJ.DisplayError(%objlasterror)
ERROR #5002: ObjectScript error: <CLASS DOES NOT EXIST>zApplyTransformation+6^%iFind.Utils.1
SSA 2e1>

Any thoughts on why this is erroring?

Working with customers who use Cache based products, while myself using primarily IRIS based products I have run into this difficulty more than once.

The only work-around I have found has been to manipulate the header of the export file generated by an IRIS system before importing into a Cache based system, not exactly easy or guaranteed to work.

The other option is to keep your code exported in an external code repository and then after you make fixes to the code re-deploy the changes to IRIS and Cache.