Preceding zeroes not passed from Process to Object

[john.hammond]

Morning all,

Hopefully a very quick one today! 

Setting up a test harness to ensure an object works as intended, but coming across this error. I would've assumed setting the data type to text would preserve the leading zeroes?

Data in the process collection:

Output Parameter


Input Parameter on Object


Collection on Object

Current Value of this collection

Any thoughts?

------------------------------
John Hammond
------------------------------

[boiko]

Good day John,

Are you reading this data from the CSV file or somewhere else? This issue could occurs due to the CSV format because MS Excel tries to "correct" the format of the data.

Regards,

Tomas

------------------------------
Tomas Boiko
Software support Engineer
Blue Prism
Europe/London
------------------------------

[john.hammond]

Hi there, thank you for responding
.
No, this data will eventually be coming from an API call/JSON, with any usual dividers (/ or -) taken out at the process layer in order for the object to enter clean, acceptable data into the application. At present, these values are being entered directly into the process layer for testing purposes.

I've tried to convert this to a date (which is what the value is meant to be), but considering how the object may receive the data (theoretically anywhere between 4 and 6 digits long), it's quite risky, and I'd rather not do too much business logic at the object stage.

------------------------------
John Hammond
------------------------------

[diane.sanzone]

Hi, John,

I looked at this for about 30 minutes and the only thing I can think is that somewhere this thing is being called as a number.  You said in your reply that this is supposed to be a date - could you do the ToDate calculation at the process layer immediately before calling the object, then have the object utilize it as a date value instead thereby preserving the leading zeroes?  If you're passing it in as a date, you should be able to use the IsDate function at the beginning of the object page to confirm the incoming data is acceptable, then further use format date to set whatever 4/6/alpha style you need for the date (or format right after ToDate in the process layer if you prefer).  I know you said you don't want too much logic in the object layer, but if you do the initial conversion in the process then you're just doing data validation in the object and that should be more palatable, hopefully.

I would add that I spent a little time creating a sample object/process to test this because I just couldn't believe your result, and my initial tests do not match what you show above.  I created a collection in the object with 2 data points, one of type text and one of type number.  In both cases I sent through the same text data item containing a value of 090321. The text data point in the object correctly shows the leading zero, the number data point does not show the leading zero.  (My institution prevents me from uploading screenshots to the portal or I'd send you a picture.)  Are you certain that there are no calculations outside what you're sending us here?  Alternatively, I wonder if this issue might be specific to your release of Blue Prism?  I'm developing in an older version, 6.4.2

------------------------------
Diane Sanzone
------------------------------

[john.hammond]

Hi Diane, thank you for getting back to me.

I hate to blame machines for this sort of thing, but after hours of pulling my hair out, a reboot seems to have completely rectified this issue. I wonder if somewhere down the line of edits, one field was set as a number, and it was still connecting to that archaic version of the object which was causing the issue. No amount of resets and refreshes seemed to get around this! Thank you for the efforts you went through - I really appreciate it!

Thanks,
John

------------------------------
John Hammond
------------------------------