hello Ganesh,

The ET. layout would be used if the document was added using ET - I assume you have 'Use entry template when displaying/viewing properties' option selected in the ET definition.

You could try use a response filter to mark properties as read-only.

hello Ganesh,

The ET. layout would be used if the document was added using ET - I assume you have 'Use entry template when displaying/viewing properties' option selected in the ET definition.

You could try use a response filter to mark properties as read-only.

Hi Ganesh, as you have observed entry templates are associated only when you add the document within ICN.  If you look at the docversion table entry template ID and entry template object store name columns you will see those properties have values when adding documents outside of ICN the columns are null. To make this work regardless of how documents are added I suggest a workflow or workflow event action whichever one you are more comfortable working with.  Your other option if you are only concerned with Datacap is to set those properties at the time the document is being created. Just set the properties on the document(s) just like you are setting other properties. 

Thank you for your input. Setting the properties before upload can indeed help achieve the best results.

After reviewing the options, I plan to proceed with the "Change Preprocessor." This approach will ensures only FileNet will have impact of change and regardless of the "Ingestion Source," it will work. Also it will avoid the need to request updates to other applications.

Please suggest if you have any other thoughts.

Thanks in advance.

Hi Ganesh, as you have observed entry templates are associated only when you add the document within ICN.  If you look at the docversion table entry template ID and entry template object store name columns you will see those properties have values when adding documents outside of ICN the columns are null. To make this work regardless of how documents are added I suggest a workflow or workflow event action whichever one you are more comfortable working with.  Your other option if you are only concerned with Datacap is to set those properties at the time the document is being created. Just set the properties on the document(s) just like you are setting other properties. 

Hi,

a Change Preprocessor serves definite purposes (one important one is setting attributes that are settable on create only) and has severe restrictions and is sometimes counter-intuitve. 

The main drowback in your case IMHO is that there is no filter on change preprocessors, so they run unconditionally. Always. Ever.

You should use a event subscription, be it synchronous or asynchronous (asnc in my opinion is enough) and put a filter on it. E-g- when the two attributes are set, do not run the setting again unnecessarily.

Hope that helps,

/gerold

Thank you for your input. Setting the properties before upload can indeed help achieve the best results.

After reviewing the options, I plan to proceed with the "Change Preprocessor." This approach will ensures only FileNet will have impact of change and regardless of the "Ingestion Source," it will work. Also it will avoid the need to request updates to other applications.

Please suggest if you have any other thoughts.

Thanks in advance.

Hi Ganesh, as you have observed entry templates are associated only when you add the document within ICN.  If you look at the docversion table entry template ID and entry template object store name columns you will see those properties have values when adding documents outside of ICN the columns are null. To make this work regardless of how documents are added I suggest a workflow or workflow event action whichever one you are more comfortable working with.  Your other option if you are only concerned with Datacap is to set those properties at the time the document is being created. Just set the properties on the document(s) just like you are setting other properties. 

Yes, that makes sense.

We just need to ensure the subscription is created for the Create/Check-In Event and add the necessary filter conditions. Thanks for the better solution.

However, I have a question:
When the Event Action updates the EntryTemplateID, will the LastModifiedBy and LastModifiedOn fields also update?

Hi,

a Change Preprocessor serves definite purposes (one important one is setting attributes that are settable on create only) and has severe restrictions and is sometimes counter-intuitve. 

The main drowback in your case IMHO is that there is no filter on change preprocessors, so they run unconditionally. Always. Ever.

You should use a event subscription, be it synchronous or asynchronous (asnc in my opinion is enough) and put a filter on it. E-g- when the two attributes are set, do not run the setting again unnecessarily.

Hope that helps,

/gerold

Thank you for your input. Setting the properties before upload can indeed help achieve the best results.

After reviewing the options, I plan to proceed with the "Change Preprocessor." This approach will ensures only FileNet will have impact of change and regardless of the "Ingestion Source," it will work. Also it will avoid the need to request updates to other applications.

Please suggest if you have any other thoughts.

Thanks in advance.

Hi Ganesh, as you have observed entry templates are associated only when you add the document within ICN.  If you look at the docversion table entry template ID and entry template object store name columns you will see those properties have values when adding documents outside of ICN the columns are null. To make this work regardless of how documents are added I suggest a workflow or workflow event action whichever one you are more comfortable working with.  Your other option if you are only concerned with Datacap is to set those properties at the time the document is being created. Just set the properties on the document(s) just like you are setting other properties. 

Yes, that makes sense.

We just need to ensure the subscription is created for the Create/Check-In Event and add the necessary filter conditions. Thanks for the better solution.

However, I have a question:
When the Event Action updates the EntryTemplateID, will the LastModifiedBy and LastModifiedOn fields also update?

Hi,

a Change Preprocessor serves definite purposes (one important one is setting attributes that are settable on create only) and has severe restrictions and is sometimes counter-intuitve. 

The main drowback in your case IMHO is that there is no filter on change preprocessors, so they run unconditionally. Always. Ever.

You should use a event subscription, be it synchronous or asynchronous (asnc in my opinion is enough) and put a filter on it. E-g- when the two attributes are set, do not run the setting again unnecessarily.

Hope that helps,

/gerold

Thank you for your input. Setting the properties before upload can indeed help achieve the best results.

After reviewing the options, I plan to proceed with the "Change Preprocessor." This approach will ensures only FileNet will have impact of change and regardless of the "Ingestion Source," it will work. Also it will avoid the need to request updates to other applications.

Please suggest if you have any other thoughts.

Thanks in advance.

Hi Ganesh, as you have observed entry templates are associated only when you add the document within ICN.  If you look at the docversion table entry template ID and entry template object store name columns you will see those properties have values when adding documents outside of ICN the columns are null. To make this work regardless of how documents are added I suggest a workflow or workflow event action whichever one you are more comfortable working with.  Your other option if you are only concerned with Datacap is to set those properties at the time the document is being created. Just set the properties on the document(s) just like you are setting other properties. 

Hi Ganesh, The downside of preprocessor is it will always happen when the document is modified/created but a little code to inspect those properties or the pending action can avert that.  One gap we have not discussed is dynamically obtaining the values you need to set for the properties. If you had 10 classes in each of 3 object stores this might be inconvenient to maintain and I could see adding more code to perform a lookup on object source class, searching for the right template then assigning the value.  Just depends on how far you want to take this, get it working now versus a robust solution that might be overkill for just a few doc classes.   

Yes, that makes sense.

We just need to ensure the subscription is created for the Create/Check-In Event and add the necessary filter conditions. Thanks for the better solution.

However, I have a question:
When the Event Action updates the EntryTemplateID, will the LastModifiedBy and LastModifiedOn fields also update?

Hi,

a Change Preprocessor serves definite purposes (one important one is setting attributes that are settable on create only) and has severe restrictions and is sometimes counter-intuitve. 

The main drowback in your case IMHO is that there is no filter on change preprocessors, so they run unconditionally. Always. Ever.

You should use a event subscription, be it synchronous or asynchronous (asnc in my opinion is enough) and put a filter on it. E-g- when the two attributes are set, do not run the setting again unnecessarily.

Hope that helps,

/gerold

Thank you for your input. Setting the properties before upload can indeed help achieve the best results.

After reviewing the options, I plan to proceed with the "Change Preprocessor." This approach will ensures only FileNet will have impact of change and regardless of the "Ingestion Source," it will work. Also it will avoid the need to request updates to other applications.

Please suggest if you have any other thoughts.

Thanks in advance.

Hi Ganesh, as you have observed entry templates are associated only when you add the document within ICN.  If you look at the docversion table entry template ID and entry template object store name columns you will see those properties have values when adding documents outside of ICN the columns are null. To make this work regardless of how documents are added I suggest a workflow or workflow event action whichever one you are more comfortable working with.  Your other option if you are only concerned with Datacap is to set those properties at the time the document is being created. Just set the properties on the document(s) just like you are setting other properties. 

Yes, you are absolutely right. In the Change Preprocessor, we can have filter on the "pending action."

Regarding your concern about property updates and fetching GUIDs from different OS sources, this is not applicable here. The ET GUID and OS GUID will remain constant values. Even when we migrate to UAT and PROD, these IDs are designed to remain consistent due to FDM.( So just we can just have them all IDs as variable in script with constant values )

If you are pointing to a different concern, could you please clarify?

Thanks

Hi Ganesh, The downside of preprocessor is it will always happen when the document is modified/created but a little code to inspect those properties or the pending action can avert that.  One gap we have not discussed is dynamically obtaining the values you need to set for the properties. If you had 10 classes in each of 3 object stores this might be inconvenient to maintain and I could see adding more code to perform a lookup on object source class, searching for the right template then assigning the value.  Just depends on how far you want to take this, get it working now versus a robust solution that might be overkill for just a few doc classes.   

Yes, that makes sense.

We just need to ensure the subscription is created for the Create/Check-In Event and add the necessary filter conditions. Thanks for the better solution.

However, I have a question:
When the Event Action updates the EntryTemplateID, will the LastModifiedBy and LastModifiedOn fields also update?

Hi,

a Change Preprocessor serves definite purposes (one important one is setting attributes that are settable on create only) and has severe restrictions and is sometimes counter-intuitve. 

The main drowback in your case IMHO is that there is no filter on change preprocessors, so they run unconditionally. Always. Ever.

You should use a event subscription, be it synchronous or asynchronous (asnc in my opinion is enough) and put a filter on it. E-g- when the two attributes are set, do not run the setting again unnecessarily.

Hope that helps,

/gerold

Thank you for your input. Setting the properties before upload can indeed help achieve the best results.

After reviewing the options, I plan to proceed with the "Change Preprocessor." This approach will ensures only FileNet will have impact of change and regardless of the "Ingestion Source," it will work. Also it will avoid the need to request updates to other applications.

Please suggest if you have any other thoughts.

Thanks in advance.

Hi Ganesh, as you have observed entry templates are associated only when you add the document within ICN.  If you look at the docversion table entry template ID and entry template object store name columns you will see those properties have values when adding documents outside of ICN the columns are null. To make this work regardless of how documents are added I suggest a workflow or workflow event action whichever one you are more comfortable working with.  Your other option if you are only concerned with Datacap is to set those properties at the time the document is being created. Just set the properties on the document(s) just like you are setting other properties. 

Hello, if you have a few classes the static values will be manageable but if you have say 10 classes you are going to have to manage those ID values somehow and any change will require code modification.  Nothing wrong with the static approach but a dynamic solution you could do a lookup to a custom object instance, retrieve the value you want then set the document object properties. In larger sites with multiple object stores and classes defining the values statically would be the least preferred option since it will require overhead. For example what if you create a new class? Going dynamic you won't need to do any code changes. 

Again- If you have a few classes the pre processor is nice and simple. If you intend to leverage entry template behavior regardless of source and have multiple classes dynamic lookup would be a real nice solution. 

Yes, you are absolutely right. In the Change Preprocessor, we can have filter on the "pending action."

Regarding your concern about property updates and fetching GUIDs from different OS sources, this is not applicable here. The ET GUID and OS GUID will remain constant values. Even when we migrate to UAT and PROD, these IDs are designed to remain consistent due to FDM.( So just we can just have them all IDs as variable in script with constant values )

If you are pointing to a different concern, could you please clarify?

Thanks

Hi Ganesh, The downside of preprocessor is it will always happen when the document is modified/created but a little code to inspect those properties or the pending action can avert that.  One gap we have not discussed is dynamically obtaining the values you need to set for the properties. If you had 10 classes in each of 3 object stores this might be inconvenient to maintain and I could see adding more code to perform a lookup on object source class, searching for the right template then assigning the value.  Just depends on how far you want to take this, get it working now versus a robust solution that might be overkill for just a few doc classes.   

Yes, that makes sense.

We just need to ensure the subscription is created for the Create/Check-In Event and add the necessary filter conditions. Thanks for the better solution.

However, I have a question:
When the Event Action updates the EntryTemplateID, will the LastModifiedBy and LastModifiedOn fields also update?

Hi,

a Change Preprocessor serves definite purposes (one important one is setting attributes that are settable on create only) and has severe restrictions and is sometimes counter-intuitve. 

The main drowback in your case IMHO is that there is no filter on change preprocessors, so they run unconditionally. Always. Ever.

You should use a event subscription, be it synchronous or asynchronous (asnc in my opinion is enough) and put a filter on it. E-g- when the two attributes are set, do not run the setting again unnecessarily.

Hope that helps,

/gerold

Thank you for your input. Setting the properties before upload can indeed help achieve the best results.

After reviewing the options, I plan to proceed with the "Change Preprocessor." This approach will ensures only FileNet will have impact of change and regardless of the "Ingestion Source," it will work. Also it will avoid the need to request updates to other applications.

Please suggest if you have any other thoughts.

Thanks in advance.

Hi Ganesh, as you have observed entry templates are associated only when you add the document within ICN.  If you look at the docversion table entry template ID and entry template object store name columns you will see those properties have values when adding documents outside of ICN the columns are null. To make this work regardless of how documents are added I suggest a workflow or workflow event action whichever one you are more comfortable working with.  Your other option if you are only concerned with Datacap is to set those properties at the time the document is being created. Just set the properties on the document(s) just like you are setting other properties. 

Yes, that makes sense.

We just need to ensure the subscription is created for the Create/Check-In Event and add the necessary filter conditions. Thanks for the better solution.

However, I have a question:
When the Event Action updates the EntryTemplateID, will the LastModifiedBy and LastModifiedOn fields also update?

------------------------------
Ganesh Jamdade
------------------------------


Original Message:
Sent: Fri January 10, 2025 03:36 AM
From: Gerold Krommer
Subject: Entry Template by default option

Hi,

a Change Preprocessor serves definite purposes (one important one is setting attributes that are settable on create only) and has severe restrictions and is sometimes counter-intuitve. 

The main drowback in your case IMHO is that there is no filter on change preprocessors, so they run unconditionally. Always. Ever.

You should use a event subscription, be it synchronous or asynchronous (asnc in my opinion is enough) and put a filter on it. E-g- when the two attributes are set, do not run the setting again unnecessarily.

Hope that helps,

/gerold

------------------------------
Gerold Krommer
Managing Director
The Document Content Profesionals, G.m.bH
Wien
+436602408515


Original Message:
Sent: Thu January 09, 2025 01:25 AM
From: Ganesh Jamdade
Subject: Entry Template by default option

Thank you for your input. Setting the properties before upload can indeed help achieve the best results.

After reviewing the options, I plan to proceed with the "Change Preprocessor." This approach will ensures only FileNet will have impact of change and regardless of the "Ingestion Source," it will work. Also it will avoid the need to request updates to other applications.

Please suggest if you have any other thoughts.

Thanks in advance.

------------------------------
Ganesh Jamdade


Original Message:
Sent: Wed January 08, 2025 09:42 AM
From: Jay Bowen
Subject: Entry Template by default option

Hi Ganesh, as you have observed entry templates are associated only when you add the document within ICN.  If you look at the docversion table entry template ID and entry template object store name columns you will see those properties have values when adding documents outside of ICN the columns are null. To make this work regardless of how documents are added I suggest a workflow or workflow event action whichever one you are more comfortable working with.  Your other option if you are only concerned with Datacap is to set those properties at the time the document is being created. Just set the properties on the document(s) just like you are setting other properties. 

------------------------------
Jay Bowen
www.bowenecmsolutions.com
Medina, OH

Hi Ganesh,

in your case I would most probably go with CP (including kind of filtering on pending action and/or property values) but in case you decide to go with async subscription you can run event action under user with "Update certain system properties" permission and change DateLastModified and Modified by to any (previous) values.
BR, Jana

------------------------------
Jana Kolodziejová
------------------------------


Original Message:
Sent: Sun January 12, 2025 05:07 AM
From: Ganesh Jamdade
Subject: Entry Template by default option

Yes, that makes sense.

We just need to ensure the subscription is created for the Create/Check-In Event and add the necessary filter conditions. Thanks for the better solution.

However, I have a question:
When the Event Action updates the EntryTemplateID, will the LastModifiedBy and LastModifiedOn fields also update?

------------------------------
Ganesh Jamdade


Original Message:
Sent: Fri January 10, 2025 03:36 AM
From: Gerold Krommer
Subject: Entry Template by default option

Hi,

a Change Preprocessor serves definite purposes (one important one is setting attributes that are settable on create only) and has severe restrictions and is sometimes counter-intuitve. 

The main drowback in your case IMHO is that there is no filter on change preprocessors, so they run unconditionally. Always. Ever.

You should use a event subscription, be it synchronous or asynchronous (asnc in my opinion is enough) and put a filter on it. E-g- when the two attributes are set, do not run the setting again unnecessarily.

Hope that helps,

/gerold

------------------------------
Gerold Krommer
Managing Director
The Document Content Profesionals, G.m.bH
Wien
+436602408515


Original Message:
Sent: Thu January 09, 2025 01:25 AM
From: Ganesh Jamdade
Subject: Entry Template by default option

Thank you for your input. Setting the properties before upload can indeed help achieve the best results.

After reviewing the options, I plan to proceed with the "Change Preprocessor." This approach will ensures only FileNet will have impact of change and regardless of the "Ingestion Source," it will work. Also it will avoid the need to request updates to other applications.

Please suggest if you have any other thoughts.

Thanks in advance.

------------------------------
Ganesh Jamdade


Original Message:
Sent: Wed January 08, 2025 09:42 AM
From: Jay Bowen
Subject: Entry Template by default option

Hi Ganesh, as you have observed entry templates are associated only when you add the document within ICN.  If you look at the docversion table entry template ID and entry template object store name columns you will see those properties have values when adding documents outside of ICN the columns are null. To make this work regardless of how documents are added I suggest a workflow or workflow event action whichever one you are more comfortable working with.  Your other option if you are only concerned with Datacap is to set those properties at the time the document is being created. Just set the properties on the document(s) just like you are setting other properties. 

------------------------------
Jay Bowen
www.bowenecmsolutions.com
Medina, OH