Jose, $lb() holds STORED values of you object instance. If your opened instance modified property(ies) then I see no point of looking into stored data, just serialize you IN-MEMORY values to JSON.

On the other hand, if a process A opened and modified instance of the object and without saving and you want to serialize the same instance from process B, then again, there is no difference between opening an object instance or using some custom serialization directly from stored data.

It is not good practice anyway to keep objects opened for a long time without saving their new values.

lastly, my comment about JSON array was that JSON array doesn't need to know the name in the name:value pair so you can easily write a custom JSON serializer to serialize directly $lb() into JSON array.

maybe I missed your original business case need, can you explain why current implementation is not good enough for you?

Jose,

how would you determine names of properties / keys for a JSON name:value pairs without opening an object instance or retrieving those names from somewhere else?

or are you happy to express it as JSON ARRAY ?

I work with Cache for decades and never knew about ExtentFunc(). There is always something to learn...

Mike, in Studio use Show Other View to display the generated INT code for the Sample. Employee class. You'll find the ExtentFunc() there. You may need to compile the Sample.Employee class first to re-generate the INT code.

Safeena,

you do not invoke web methods directly. You need to create a client class by consuming a WSDL file that your service exposes. There is a wizard that guides you through the process of client creation. Apart to client class itself the wizard also generates all data types used by a web service. Please consult documentation here.

There are some other option when using Ensemble but I suggest you follow the link above.

Thomas,

Hope I understood your question correctly, if not then let me know.

In general, when dealing with XML VDoc documents (files), you need to create a production that uses services based on

EnsLib.EDI.XML.Service.FileService, operations based on EnsLib.EDI.XML.Operation.FileOperation and a routing process - EnsLib.MsgRouter.VDocRoutingEngine. There is no need to do any coding, just supply parameters in the production diagram.

You may need to provide DocSchemaCategory setting for a service, for this, you need to import the XML Schema, using Import button at Ensemble->Interopeate->XML->XML Schema Structures page.

for actual routing, you need to design a rule, and supply path to the document element/attribute that's used to decide where the rule sends document to. I prefer using XPATH expressions for this.

An example of routing rule contents is here:

<ruleDefinition alias="" context="EnsLib.MsgRouter.VDocRoutingEngine" production="tzp.dasta.router.Production">
<ruleSet name="" effectiveBegin="" effectiveEnd="">
<trace value="Document.{/dasta/is/ip/lo/loi/@material}"></trace>
<rule name="">
<constraint name="source" value="Dasta3Zadanka"></constraint>
<constraint name="msgClass" value="EnsLib.EDI.XML.Document"></constraint>
<constraint name="docCategory" value="ds030101"></constraint>
<when condition="Document.{/dasta/is/ip/lo/loi/@material}=&quot;B&quot;">
<send transform="" target="Dasta3Biochemie"></send>
<return></return>
</when>
<otherwise>
<send transform="" target="Dasta3Mikrobiologie"></send>
<return></return>
</otherwise>
</rule>
</ruleSet>
</ruleDefinition>

You can create a VDOC document from a persistent (any, not only persistent) object, as long as it extends also from %XML.Adaptor. First, you serialize your object instance to XML stream or string, and then using ImportFromString/ImportFromLibraryStream (or other - see online reference for EnsLib.EDI.XML.Document class) method you instantiate a VDoc document.

HTH.

Dan