Regarding unused filler fields in Harmony Core generation and request structures.

[tscaff]

I apologize if this sounds like an odd or kind of simple question, but there are fields on the repository, that when Harmony Core is generated, are showing as part of the request and response Metadata that are passed around on the structures structures.

We were wondering if there is a way to exclude them from the request and response structures to help minimize the payload and wordiness of the requests and responses?

From what I have gathered from conversations around our development group, some folks are creating whole new repository structures which are derivations of the original structure which have limited subsets of fields from the original structures. That seems like that may be creating a bit of extra work that could be avoided. Any thoughts on this?

[SteveIves]

Hi Tom,

If you want to exclude specific fields, always, you can do so by adding the text HARMONY_EXCLUDE to the field's long description.

CodeGen also has a feature called field subsets, which allows you to define subsets of fields to be processed. Subsets can be defined in two ways, either in the repository, by adding text to the fields long description, like this:

@SUB=SUBSET1
@SUB=SUBSET2

And then referencing the subset in your codegen command:

codegen -s STRUCT1 -subset SUBSET1 ... (CodeGenTask.Subset property (String))

Or entirely on the command line:

codegen -s STRUCT1 -fields FIELD1 FIELD2 FIELD3 ... (CodeGenTask.SubsetFields property (List<Tuple<String, String>>))

I have never done this when creating Harmony Core data objects, but in theory, it should work, so long as you use a structure alias to alter the name of the class that is created and don't exclude any fields that are used as key segments.

[tscaff]

You are pure gold @SteveIves! Thank you so much. That's what I was looking for.

[SteveIves]

Actually, thinking about it some more, while @HARMONY_EXCLUDE will work to exclude specific fields, the whole field subset thing won't work for you in the Traditional Bridge world if you are using code generation driven off a Synergy method catalog. The problem you will hit is that while you can manipulate codegen to produce data objects all based off a repository structure but with different names and properties, you won't have an actual repository structure to name in parameter definitions in the SMC.

If you're not using the SMC and related code generation then you could make it work for sure, but then you'd have to manually code a lot of additional stuff, including dispatcher classes on the traditional side, and controller, service and request/response classes on the .NET side.

I can see this being a popular feature if we can make it work, but a solution is not currently obvious.

[tscaff]

No problem. I think specific field exclusion is all we need to do at the moment. But that is an interesting concept you mentioned, and yes that could be a nice feature.