Often the unresponsiveness after loading a lot of data is due to Creatio's live update feature. Basically, many Creatio objects have live update enabled, which means for any add or update, it sends a signal back to the browser so the browser reloads the UI to show the updates/adds that occurred on the server. When loading in a large set of data, that causes a socket back to the browser for every single add or update, which the browser then reloads the data causing a request to be made back to the server to retrieve the newly added or updated data. So if you're loading a million records, that could also mean a million socket signals sent back the UI, and if your browser is open and viewing that record type, possibly a million requests to the server to load the data. All of that extra communication can cause things to get overwhelmed for large amounts of data to say the least. This feature is great for normal user activity, but when loading large amounts of data causes too much overhead. (I show below how to turn this feature off)

To get things responding again, you can restart the Creatio system which scraps all the pending socket requests.  Don't do it while the data is loading, but after or when paused. I use Clio Explorer for this. Once installed and you've registered the system (also need to install Clio API package in the system which Clio Explorer can do - refer to linked article), you'll see a restart option on the menu for the registered system.

However, if the system currently isn't responding at all, you might just need to contact support and they can restart the system from their end (but for next time, this option of using Clio is quick and easy).

While you're loading the large amounts of data, you can turn off the Live Updates feature altogether. Then once the data is all loaded, turn it back on again. 

To turn off Live Updates for the entire system, go to the features page https://yourcreatiosystem/0/flags then search for the feature called LiveEditing and disable it (see below). Uncheck "Is enabled" (if checked) and also uncheck for "All employees" and also "All external users" (technically, only needs to get disabled for the user you're connecting via DataService or OData with, but I just turn it off for all). Then click Clear Cache button.

Now, it will no longer add all that extra traffic with sockets back to the browser and reloading of data from the server. Then once complete with the migration you can turn that back on again. 

Ryan

Hello,

Could you please check whether the UseCaseInSLMOldFunc feature is enabled in your environment?

Malika,

Hi, yes the feature is enabled. Although I can see the lifecycle behavior does not change when it is disabled. Would you suggest doing that?

Hubert Pacia,

Could you please try disabling the UseCaseInSLMOldFunc feature and check whether the issue still occurs?

When this feature is enabled, the processing goes through the old business process, while the new approach relies on listeners with a clearly defined call order. With the new logic active, this kind of issue shouldn’t appear. 

Malika,

Thank you, I will do that and update you here in case this reoccurs.

Hi, Sergejs. You should do it as following:

{
	request: "crt.HandleViewModelResumeRequest",
	handler: async (request, next) => {
		await next?.handle(request);
		setTimeout(() => {
			request.$context.Param1 = someValue1;
			request.$context.Param2 = someValue2;
		}, 300);	
	}
}

Dmitry S,

Can you please clarify what is someValue1 and someValue2 in your example? As far as I can understand, you are setting attribute value inside same page in the HandleViewModelResumeRequest.

My scenario is slightly different, I am trying to pass the attribute value from another page. So for instance - I have a button on a page1, this button has a custom click handler, where I call CreateRecordRequest with some parameters. In result page2 opens and I want to set it attribute with the value from the parameter i passed in CreateRecordRequest. I hoped it works automatically, but it's not. I tryed your HandleViewModelResumeRequest code with little modification, but attribute value still is null for me.

			{
				request: "crt.HandleViewModelResumeRequest",
				handler: async (request, next) => {
					await next?.handle(request);
					setTimeout(() => {
						const a = request.$context.SomeAttribute; //a is null here
					}, 300);
				}
			},

Sergejs Sokolovs,

You are sending something from parent page to child page ok. So in data model of the created child page you have them, yes? And page is opened.

So, you can get them on the created page as 

const attribute = await request.$context.UsrAttributeName; 

or the problem occurs when you're trying to fill smth virtual? Which exists on the page, but not present in the entity itself? if so, I'll check this tomorrow.

BTW. 

as a workaround you can do the following:

1. You can create some process like this one with open preconfigured page element. You can configure some process parameters, which will receive data you want to display. You can link these process parameters to the desired page. On the page are all of those parameters accessible.

2. Instead of using record handlers you can run this process from some custom handler on the page somehow like this (also not forget to define ProcessModuleUtilities). Process should open page with all required fields filled. 

["@creatio-devkit/common", "ProcessModuleUtilities"], function (sdk, ProcessModuleUtilities)

You can use something similar from FD sdk indeed, this example was taken from FD page, but it uses CI logic.

const printableId = reportTemplate.value;
const args = {
	sysProcessName: "UsrGenerateContractByTemplate",
	parameters: {
		ContractId: contractId,
		PrintableId: printableId
	}
};
ProcessModuleUtilities.executeProcess(args); 

As a workaround approach, I've been using BroadcastChannel API to pass other attribute (non-model) values to the opened page. See the comment in this thread from Edward https://community.creatio.com/questions/open-custom-freedom-ui-page-custom-button-opportunity-edit-page-and-pass-opportunity

Ryan

Ryan Farley,

Yeah, already started to think about that solution, but hoped there is more native one. It's little bit frustrating, that params are not supported, but it's great that we have a workaround. Thanks!

Hi, 

I haven't done this yet by myself on lookup field, but on quick filter field with lookup type, the whole idea is the following. This is normal lookup fields parameters:

"PDS_Owner_7mvaqih": {
	"modelConfig": {
		"path": "PDS.Owner"
 	}
},
"PDS_Owner_7mvaqih_List": {
	"isCollection": true,
		"modelConfig": {
			"sortingConfig": {
				"default": [
				{
					"columnName": "Name",
					"direction": "asc"
				}
			]
		}
  	}
}

as we can see here PDS_Owner_7mvaqih is a field, and PDS_Owner_7mvaqih_List is some dataset, where some owner lookup values are stored. So you can manipulate with this lookup via JS as you wish (naturally, the structure of you values has to match exactly as it is by default), as you can see here in example: 

{
	request: "crt.HandleViewModelResumeRequest",
	handler: async (request, next) => {
		await next?.handle(request);
		const department = await UsrCommonModule.getCurrentUserTeam(true);
		if (!Ext.isEmpty(department)) {
			request.$context.PageParameters_LookupParameter1_7pw8znf = department;
			department.checkedState = true;
			delete department.primaryColorValue;
			delete department.primaryImageValue;
			request.$context.QuickFilter_orifxps_Value = [department];
		}
	},
},

here we delete quick filter value by default and feel it with one record (actual user's department):

department.checkedState = true;
delete department.primaryColorValue;
delete department.primaryImageValue;
request.$context.QuickFilter_orifxps_Value = [department];

So, referring to the first part I can do with PDS_Owner_7mvaqih_List everything I want by something like request.$context.PDS_Owner_7mvaqih_List = [{...}, {...}]

Exact structure for the request.$context.PDS_Owner_7mvaqih_List you can find out via debugger in the request.$context object.

I'll be glad to answer your possible questions :)

Hi Rishav, you mean this?

if so, you should add (and/or enable) AllowCreateAngularSchema feature. This action will after log on show the mentioned option. Other way is to create replacing page normally by

and then edit it's source code in configuration section:

Hi Dmitry S,

I’m trying to achieve the following:

My goal is to use the base Case Management features and extend them. There are different case types, and based on the type, both the UI and data models will vary significantly. One option is to create a replacing object, add all 300 different fields to it, and then perform all the customization in a single page, but that approach would not be maintainable.

So, I want to inherit case management page and utilize it for different types of cases. Suppose There are 10 different types of case, base UI for these pages should be similar to what default Case Management Form UI,  for each pages I will have different fields (different data sources for each Case). When I use Angular Replacing View Model, it completely replaces the original Case form page, which is not the behavior I want.

I am not sure if i am doing something wrong here, but I assume there must be a way to inherit the structure ("skeleton") of a form page and customize it accordingly. 

Also another option is to just create new form pages,  but for every case I have to develop a new one from scratch. I would like to avoid that :) 

Thanks

Rishav

Rishav Kumar,

may I send you instruction via e-mail please?