We have a record D in the flat file with the following structure:
D^Field1^Field2^Field3^Field4. And now, we want to format the Field2 with the logic(when Field1==“AA” then Field2=Field1+Field2; else Field2=Field1). So can it be done with a format service? Thanks a lot.
This is logic that is probably best placed within your transformation logic. Given the info so far, I would create a service named “getFieldsFromD” that would use the logic you describe to return the appropriately named fields.
Thanks reamon. We have a standard process service of the flat files, but some times, our user may need us to do some conditional formatting like I showed before. So we need to develop some transformation services to do this as your suggested. And the problem is, we need to get the message types and branch on it to invoke the transformation services in the standard process service. Also,will the formatting service be more efficient than looping in a transformation service? Thanks a lot.
A format service, as defined by pub.flatFile:FormatService, is applicable in relatively narrow scenarios. It takes just one field as input. And is invoked only in convertToString and convertToValues. So you won’t be able to implement anything like the logic you mentioned in your first post.
Define a flat file schema that represents the structure of the source file as is. Then define 1 or more schemas that represent the various output document types that you need. Then, when you’re processing the source file, determine (by whatever means) what output document type you need to create. Then call the services that translate the source type to the target type. These translation services can be as sophisticated (field manipulation as described in your first post) or as simple as needed.
If you separate the definitions and logic by document types, things will be easier to understand and maintain.
Thanks reamon for all your information.