Hi there,

I use the IBM Business Automation Workflow embedded JavaScript syntax (for example, <#=tw.local.description#>) to express the narrative. Tw.local.description can consist of many characters. 100.000 or 500.000 characters are possible.

Are (performance) issues to be expected with these many characters? Thanks.

------------------------------
------------------------------
Frank
------------------------------
------------------------------

I doubt anyone has run this experiment to give you a definitive answer.  I do know that I've seen that Process Instances with very large execution contexts (think 100's of tasks) can take a very long time to return the request for instance data.  I'm not sure where the slow down for those takes place as it is internal to the engine.  If it is due to the number of tasks then this might not impact you, but if it is due to the amount of data it may.  I would guess it is more closely tied to the number of tasks so you may be okay.

I do have significant worries about the underlying use case for this as that much data feels like it really should live somewhere besides the Narrative of an instance.  Maybe as an attached document, maybe as an entry in a No-SQL repository somewhere.  Not knowing exactly what you are doing I'm not clear on the right answer, but I don't see 100K - 500K worth of text being something any human would look through, so it feels like you are jamming something into an available field that likely really belongs somewhere else.


------------------------------
Andrew Paier
------------------------------

I agree to Andrew. Avoid this amount of data, since it may be saved to the BAWDB during the saving of the execution context and influence the overall performance of the system. Keep it as small as possible and if required, reference to a system that lives outside of BAW.

------------------------------
Torsten Wilms
------------------------------

Original Message:
Sent: Fri September 18, 2020 02:14 PM
From: Andrew Paier
Subject: Lots of characters in narrative: Performance issues expected?

I doubt anyone has run this experiment to give you a definitive answer.  I do know that I've seen that Process Instances with very large execution contexts (think 100's of tasks) can take a very long time to return the request for instance data.  I'm not sure where the slow down for those takes place as it is internal to the engine.  If it is due to the number of tasks then this might not impact you, but if it is due to the amount of data it may.  I would guess it is more closely tied to the number of tasks so you may be okay.

I do have significant worries about the underlying use case for this as that much data feels like it really should live somewhere besides the Narrative of an instance.  Maybe as an attached document, maybe as an entry in a No-SQL repository somewhere.  Not knowing exactly what you are doing I'm not clear on the right answer, but I don't see 100K - 500K worth of text being something any human would look through, so it feels like you are jamming something into an available field that likely really belongs somewhere else.


------------------------------
Andrew Paier
------------------------------

Hi Frank, I would assume that the tw.local.description is saved with the execution context in the database. Therefore I would keep it as small as possible to avoid unnecessary overhead during saving.

------------------------------
Torsten Wilms
------------------------------

Hi Frank,

As others have suggested, using embedded script <#=tw.local.description#> to store such long text is definitely a bad idea. 

What is it that you're trying to achieve? Explain that and I'm sure people can give you way better approaches.

------------------------------
Thong Huynh
Sydney NSW
------------------------------

Hi,

thank you very much for all replies.

Tw.local.description can consist of HTML content with a lot of styling. The description should be included in task notification mail. First of all, I've limited tw.local.description in narrative to 250 chars. Because of the styling, the user isn't able to see the important iniformation.

I also don't want to remove styling, because the descrition in the mail could become difficult to read.


------------------------------
------------------------------
Frank Schunig
------------------------------
------------------------------

Hi Frank, 

I see. So you're using embedded scripts for templating your emails. I have used that approach as well in my recent projects. There was no performance issues that I could see.


------------------------------
Thong Huynh
Sydney NSW
------------------------------

Original Message:
Sent: Tue September 22, 2020 03:19 AM
From: Frank Schunig
Subject: Lots of characters in narrative: Performance issues expected?

Hi,

thank you very much for all replies.

Tw.local.description can consist of HTML content with a lot of styling. The description should be included in task notification mail. First of all, I've limited tw.local.description in narrative to 250 chars. Because of the styling, the user isn't able to see the important iniformation.

I also don't want to remove styling, because the descrition in the mail could become difficult to read.


------------------------------
------------------------------
Frank Schunig
------------------------------
------------------------------

Hi Franck,

We've used extensively the narrative to give an overview of the current process data and we reached about 10 A4 pages of data and we've never had performance issues, this narrative are being sent in email notifications and available on the task details view also

Regards,
Joao 

------------------------------
Joao AMADOR
------------------------------