1
Vote

Join Fields object should accept empty fields

description

It has been found and experienced that, with the use of the Join Fields object of the Data Manipulation Integration Pack to "Translate International Characters" (i.e. è, ï, ô, ñ, and alike), it is quite useful to add an extra "dummy" field (field03) beside the two obligatory field01 and field02 parameters in this object and the delimiter of course.
 
The reason is as follows: Whenever the value or contents for one of the two obligatory fields is missing or empty (or both for whatever reason, which poses another question), the "Join" cannot be executed, for it won't join something with nothing - i.e. the missing value! By taking up an extra (dummy) field with a value that always exists, either hard coded or from a "get value" like in the "Query XML object, we most often use, the fields specified in the "Join Fields" object can be joined and will pass on the data to the next objects and eventually to the "Split Fields" object. In that case it doesn't matter if the field is used or not in the work flow thereafter. It is just there to join something with nothing and then something, just to be able to join!
 
This is only a workaround and it provided a quick, but sufficient, solution to issues we faced when one of the values of the fields we used (as in default configuration with only two fields and the delimiter) was found empty. The work flow went on and didn't come to a halt, as it did without the extra field.
It leaves the 'two fields empty' question open though, but I think the answer will be self explanatory, given the scenario described previously.
 
The question we face here, and like to have answered, is however: Why can't a value be just "Empty" and, for that matter, make it possible join something with nothing? In that case one will be able to use the default configuration, if you do not have that may text strings that need to be joined to process the text in one go.
The workaround presented here is something that might be added to the User Guide for this IP. With the secription of the object it only states: "• FieldXX – A series of 50 properties to be used as input strings to build the result. Field01 and Field02 are required properties while Field03 through Field50 are optional.", but in the way we are using it, it has been found quite a relief to just add one more and be out of worries. Especially when you suspect one of the fields may be empty.

comments

jfanjoy wrote Dec 14, 2010 at 6:42 PM

Re-iterating to ensure I am clear on the proposed change:

The desired change is that the "Join Fields" object which currently performs run-time validation that "Field01" and "Field02" are populated with a value should accept empty values in either field (or any selected optional fields for that matter) as the run-time data may legitimately be empty.

Am I understanding this correctly?

Jeff.

rvaneerd wrote Dec 15, 2010 at 5:28 AM

Hi Jeff,

Working with Rick, I managed to implement his suggestion successfully.
From what I understand:
  • Rick proposes a change in the "User Guide" to mention this behaviour and the accompanying bypass.
  • You're proposing a change to the Data Manipulation IP, which would make the bypass obsolete as the "Join Fields" could handle empty fields in the first two required fields (which will make the User Guide addition obsolete ;-) ).
Regards,
Rob.

ps. I've mentioned this before, but I'll do it again: If you're going to (propose a) change (to) the Data Manipulation IP: Please investigate customizable labels for the fields used by the "Join Fields" and "Split Fields" objects. Meaningfull names work better than "Field01", "Field02"........

RickydB wrote Dec 15, 2010 at 7:07 AM

Jeff,
You've understood my suggestion / remark correctly.

In short: If the default Fields in the Join Object have to be populated and this is the desired configuration, I suggest to add the information of taking up an extra field "Field03" as a dummy or with published data, one knows will always have a value, to the object's section in the User Guide.
The sole reason is, that we've found the object to halt the workflow if one of the values is missing (empty), in the case where we were using this object with only the default fields, namely Delimiter, Field01 and Field02.
This has also been explained by Rob in his comment on the subject.

jfanjoy wrote Dec 15, 2010 at 4:14 PM

Ok, I understand. The scenario for which the Join Fields object was envisioned was to join together fields that always contained data which is the reason for the validation. I never took into consideration a desire to join fields where data may or may not exist.

I'll schedule this change to be included in the next release.

wrote Dec 15, 2010 at 4:15 PM

wrote Dec 15, 2010 at 4:16 PM

RickydB wrote Dec 16, 2010 at 10:07 AM

Jeff,

To be honest and clear about this: We have no desire in joining fields where data is not present. It is merely an observation that we made whilst working with the default configuration and one of the fields used contained no data and which fact caused the work flow to halt.
As I have stated earlier, if the current configuration is the desired functionality of the object, also because of the validation (which I now understand caused the observed error in the first place), then please leave it like that. However, if you decide to do as such, please add a comment in the User Guide stating: if one of the two fields used may have no value or data, or has the possibility of not having data on all occaisions, extra care should be taken to escape the workflow (with for instance an error message) or use an extra "dummy" field. A field that is known to always contain data, which which the object always is able to "join" and continue succesfully.
Rick

wrote Feb 14, 2013 at 6:31 PM