Hi all, I'm using Export CDT To Excel smart service. Let

Hi Mihaioctaviant, Did you verified your excel base template that it is configured to two columns only

@pavithrac : I don't see the reason why I need to configure the excel template in that way. As long as i'm passing the starting cell, it will know where to put my array of cdts.
sorry if I didn't got your message.

just for confirmation reasons could you post a screenshot of your CDT including field names, and an accompanying shot of the value you have set in "Cdt_fields_to_export" ?

@mschmitt: you have a point so here is the exact use case, see the order I desire and the whole cdt structure.

Hmm, that looks about right. I'd just done one of these myself the other day and didn't have any issue, though I may not have tried a custom ordering like yours. For reference, are al CDT fields Text type? Also, just for troubleshooting, what happens if you temporarily change the expression to just ={"hno6"} for example?

The first and last fields are of type text, the rest are integer type.
But if I change the expression to just ={"hno6"} it will export the "description" field (first one), that's why I'm afraid I must create another cdt if I want to achieve my goal here.

Oh i see - I'm not sure of the technicals but I think this plugin might have finnicky issues with other data types. What I've done in other places is to create a new global or generalized CDT with an arbitrary number of Text fields (starting around 10 or whatever you think your use case will be), i.e. "field1", "field2" ... "fieldN". Then in a script task right before the Excel node, you can copy your desired data into the fields of that CDT, so that they'll be cast as text (and you can use this chance to do any other formatting that might be necessary, too).

I see, thank you for your thoughts on this.

@mihaioctaviant Just to confirm from a custom ordering and data types perspective, we have 22 fields in the CDT out of which many of them are Text and few are Number Integer. And as of now we are using 17 fields as of now in the 'Cdt_fields_to_export' attribute and that too in a entirely different order from the order, the CDT maintains. We have been using the smart service for more than one and a half year and neither there is a single issue till date in the data being exported (the plugin is also tested to work on huge datasets) nor with the configurations. Further I also remember that the plugin worked well when there are fields of type Boolean in the CDT. And I have to say that all the fields in the CDT are single and there aren't any nested CDTs, that is, the CDT is flat.

What I have noticed in my implementation is, if there are any fields of type multiple or nested CDTs in the main CDT, the plugin doesn't work in a desired manner. So I have gone for creation of a formatted CDT which is flat (no nested CDTs) and only contains fields of single type.

It might be worth focusing on the other configurations in the smart service and the structure of the CDT as well.

It might seem like a weird thought - but is there a chance of any influence on the working of smart service because of the number in the name of CDT fields?

Hope the above information will be of some use to you and we have extensively implemented the same smart service in one of our projects and I would be happy to contribute just in case if you come back with questions.

As said by other practitioner, it hasn't got to do anything with the template (such as n column based) and your understanding re the same is correct.

Thanks @sikhivahans. I confirm that my cdt is flat with every field single. There could be a possibility that the numbers in the field names have some sort of influence on the expected result, i'll do some further tests.