09-02-23 09:46 AM
Hi there, I'm new to BluePrism and I have an object that uses two collections whose first column is the exact same.
I need to modify the same row of the two collections in every iteration. Those collections' size vary and sometimes they can be 4k-10k rows long. The problem is that the modification of those rows takes a lot of time when that happens.
I already know the exact index of the rows, the program speed down occurs because the code stage that takes and modifies that rows needs to load the entire tables as inputs and outputs. Is there any more efficient way to do this? How can I load into the code stage only the row I want to modify?
Thank you for your time!
09-02-23 10:03 AM
Hi Jose Luis,
On object 'Utility - Collection Manipulation' you'll find action 'Utility - Collection Manipulation':
...that might do what you need.
Alternatively, if you happen to be looping through the collections anyway, you could change a row value by a calculation stage.
Happy coding!
----------------
Paul
Sweden
09-02-23 10:07 AM
...additionally, when wanting to do something with a collection, or perhaps an XL file: just open the corresponding object in your process and see what actions are in there. In your case of collections, there are several objects each sporting different actions, so you check them all.
Happy coding!
----------------
Paul
Sweden
09-02-23 10:18 AM
Hi Paul,
I thought about using that objects' actions but they happen to work the same way as my code. They take those inputs, included the collections, load them into a code stage and make the necessary changes. That is what I'm currently doing on my code stage and what's taking so much time (1-1.5 seconds more for each row when I have collections this big).
Also, I'm not looping through the collection, I don't need it because I have the index of the exact row I need to modify in each iteration.
Anyway, thank you so much for your answer!
09-02-23 11:28 AM
Hi again,
I reckon rather sooner than later your company has to make a choice if it is ok to use code stages or not. You might end up with many objects and actions only slightly differing from a standard out of the box VBO actions and your colleagues not seeing the trees through the forest.
Personally, I prefer to avoid code stages. We only use code stages if performance, speed, or memory management dictate looking out for an alternative to a BP native action. Whilst code stages may be natural for a programmer, many BP developers are not programmers, and your company might end up with a load of code stages that no-one can maintain but the programmer - you. And if the programmer moves on to the next job...
Happy coding!
----------------
Paul
Sweden