Objects: Use Cases for 'Initialise' and 'Clean Up' Pages

[stepher]

This question really comes down to finding out how others are using the 'Initialise' and 'Clean Up' pages of their custom application Objects.  It has been a few years for us, and with the exception listed below, we almost always just leave these pages blank. (Can we delete them?  I've never tried.)

For the 'Initialise' page, the only function we have come up with is to set standards for global time variables (XS, S, M, L, XL) to be used within the Object.  This was introduced by a consultancy, and we have adopted it without too much thought. I am not sure it really gets us anything, as I usually end up setting my Wait/Sleep parameters explicitly.  But it is something.

We have nothing for the 'Clean Up' pages.

I was just curious what others are doing.  Maybe there is something obvious that we are missing, or if there might be something that we could latch on to.

Thanks in advance,

Red

[Michael_S]

Great question @stepher! I'm summoning a few of our top Community answerers on this question as there's likely to be multiple different approaches... and lots for everyone to learn!

Can you help @devneetmohanty07, @harish.m, @Athiban_Mahamathi, @Daniel_Sanhueza, @shreya.khot, @Neel1 ?

[harish.m]

Hi Stepher,

For Initialize  page:
I have used  global variables  in addition to wait time mentioned in your post,
so that way its easy to look all the global variables in one spot
In the past I have used launching the web application and excel instance  as well.


Clean up:
I have used for closing the instances
In the past I have used these actions for the wrapper objects
Wrapper Objects:
Lets say if I'm working   on Application 1 and created objects, Instead of using  Application 1  actions in the process  I have created/used wrapper objects to call all these actions. I have used Initialize and clean up  mostly while using wrapper objects other instance, I used mostly global variables




thanks,
harish

[Daniel_Sanhueza]

Hey @stepher

The Initialise and Clean Up pages are called automatically by the process, the init page when the object is called and the clean up page when the process ends. That's the short answer and if you delete one of them, the process will fail.

This pages are commonly used (in his flow) to store any global data item that any other action of the object can use. It is a best practice because it is easy to find, its not a requirement ofcourse, you can put any global data item in an action that you created but when someone need to change something, will need to find that action and its not the best option.

Now, in the init page you can change how the Business Object behave, for example;

Run Modes;

By default, when you create a BO the runmode is set to exclusive. If you change it, you have the possibility to run multiple instances on the same resource at the same time. Most of the use cases need an active GUI, but that doesnt mean that can't run a background process. Personally, I always set this at Foreground, just in case if a background process can run at the same time. (i.e excel automations that could work in the back)

In the same tab, you can set if you want that BO to be Shareable, With this checked you can share his application modeler to other object, very usefull when need to create multiple BO targetting the same platform but you dont want to use all the actions that came with the parent object.

I cant talk much about Global Code tab and Code Options tab because thats where the external references, imports and the code itself are. Use the MS Excel VBO as example, you can find there functions, Dll's and imports that are needed to run every actions inside the BO. For example, If you use "MS Excel VBO:Create Instance" followed by a "MS Excel VBO - Extended: Open Workbook" it will fail because the instance was created on a different object. Not an expert on this and I could be wrong, I hope someone could add more info🙂

Best practices;

When you call an action from a process, init page automatically runs, we know that. But also every action on the Business Object will be consumed in memory even the ones that the process dont use and it'll be released at the end of the process when the cleanup page runs. That's is why as a best practice it is better to have modular objects automating specific steps and not  a single object with tons of actions automating the entire platform, also remember that only one dev per object can work. If you dont use this approach, then you cant get help from others and the developing process could take longer than it really needs.

Hope this help, I'm looking to see others reply on this!😊

[harish.m]

I agree with Daniel regarding  using modular objects instead of using  Wrapper objects,

As part of trying different things I implemented wrapper object in one of the project some time back, but  it is definitely not a good option to try, since it will take lot of time to implement the only suggestion there is  try wrapper object if you are planning to create and use only one published action for the whole object.

Thank,

Harish 

[stepher]

I appreciate the feedback so far.  Thanks.

Locating all of the Global Variables together makes sense to me.  I often do that at the Process level.  I have to say that I personally have very few instances of Global Variables at the Object level, but I support the idea.  Automatically starting an application at the very start of a Process seems like it could be problematic, but I will look into that a bit.

We also do have a handful of Wrapper Objects, or maybe they are 'Modular Objects', I am not sure I am seeing the distinction.  In our usage, the WO usually relates to a very specific, but common, set of steps/actions.  We have WOs for a couple of Excel actions, loading documents up to Decipher, and sending out emails via Outlook 365.  Rather than have each and every instance at the Process level go through the identical steps, the Processes call the WO.  This is not so much about memory usage, but a) it makes the Process a little cleaner to read, and b) it offers a single point to manage any changes/updates that may be needed for these common steps.

Again, thanks for the information.  And please keep the conversation going.

Red

[MichealCharron]

@stepher 

If you want to see a good example of a Clean Up page, look in the Excel VBO VBO. That page takes care of closing down all the instances of Excel that the VBO has opened without you having to do it. While debugging something with that VBO you can just hit reset to close everything. 

[stepher]

Thanks, Michael,

What is actually kind of funny is that one of our 'Wrapper Objects' is something I came up with to address orphan processes.  The WO checks a list of a couple dozen of the 'usual suspects', and if any of the processes are running, it will terminate them.  As a rule, we set this WO at thee points in the Process: at the very beginning (to clear any orphan processes left by other automations), at the end of the 'Happy Path' (to make sure the automation itself is not inadvertently leaving an orphan process), and at the end of the Terminal Exception path (where there is almost certainly something to clean up).  A bit of overkill, to be certain, but this drastically reduced the number of recurring terminations we were seeing.

Still, I can see the value in the idea.

Thanks,

Red