There is definitely no pattern to WHICH words or phrases are fair game, though.By April Eggers, Senior Software Developer, FDIĪs a front-end developer, I use JSON – a lot. The break is never in the middle of a word, however, but always replaces a space between words. Some of the data contains HTML-encoded formatting (because the database contains a number of rich-text fields, with bulleted lists, etc.) To have cleaner data, I chose to use the HTML to Text action.
Nonetheless, it would be nice if that but could be addressed.Īs an example, my test JSON file is 247,506 characters long (including asc(13) line-breaks where appropriate), and is an export from a proprietary database.
(Maybe I'll try to "clean" it further downstream when displaying it InfoPath comes to mind.) So, that action is off the hook.Īt this point, I'm just going to change the SharePoint columns to rich-text Multi-Line columns (to accomodate the user-formatted input), and tell the stakeholders that "cleaning" their verbose, formatted input is not practical at this point. Using the "body" of the HTML to Text action, the Parse JSON action has no choice except to add the "\n" new-line character to make it legitimate JSON data. There is definitely no pattern to WHICH words or phrases are fair game, though. The break is never in the middle of a word, however, but always replaces a space between words. For example, the next line is 46 characters long the one after that is 122 characters long, etc. While the first line break it adds is at position 256 (as one might expect when dealing with strings), the rest are added seemingly at random. That action appears to ignore the original line breaks, adding its own seemingly at random. My apologies! I stand very much corrected: it is the HTML to Text action that is introducing the line breaks, not Parse JSON, which is using the results as input.Īs an example, my test JSON file is 247,506 characters long (including asc(13) line-breaks where appropriate), and is an export from a proprietary database. "Phase\n2" "Phase 2"!) I find that I need to go into the list and edit out the line-breaks (which appear as an HTML "") manually, even from Single Line of Text fields.ĭoes anyone else experience this? And what can be done? I tried using string substitutions, but Flow acts like the break isn't there yet it still returns it with a break in-between the two words! This workflow already takes well over two hours to run, so I'd rather not do too much text manipulation if I don't have to. (Of course, I checked the input file and there are no line-breaks found there.) To compound the issue, there are rules in the list itself that use this data in other calculations and JS link formatting, but which now don't recognize the data as "valid" (i.e. For example, in the screen shot shown here, you can see that the output of the simple, short string "Phase 2" ends up with a newline instead of a space.
Unfortunately, I am finding that the results that are returned seem to have random line breaks added between words for no apparent reason. I am using the Parse JSON action to work with a data file of >13k rows (if that's important) which then updates the information in a SharePoint list.
0 kommentar(er)
