You are viewing limited content. For full access, please sign in.

Question

Question

Creating Dynamic [Nested] Fields in Laserfiche by avoiding SQL.

asked on February 9, 2017 Show version history

Hi Community,

I have been struggling to find an alternate way of creating Dynamic Fields in Laserfiche [as part of the repository metadata fields area, not forms], where Dynamics Fields is not using SQL [a business requirement].

I did find 2 ways so far to create dynamic fields (one by an external database in SQL, the other creating a SQL view in the existing Laserfiche database), but the business wishes for no access to SQL be given to users. The Laserfiche Administration Guide and all other sources indicate that SQL is the only and recommended workaround.

Any ideas? Can this be built in a workflow? Is there a place in the repository where the values in the dynamic fields can be easily managed without granting too much access?

I was told that dynamic fields can pull metadata from a blank document placeholder (based on a Laserfiche demo that was presented) - can someone shed some light on this?

Thanks!

0 0

Replies

replied on March 16, 2018

We've also used Forms and Workflow to create a "front-end" form for editing those values in SQL. A Form that performs a lookup in SQL to retrieve all those "list choices" and then once the user edits or adds Forms calls Workflow which pushes those values into the SQL table again. Then the Dynamic Fields can use SQL directly AND the user can edit those values without needing access to SQL. 

1 0
replied on February 13, 2017

Dynamic fields do not require that the user be granted access to the SQL table, only the LF server needs access.

0 0
replied on February 14, 2017

True - But there still needs to be someone to perform edits to the SQL table in the event that a field needs to be renamed, updated, etc and to create the tables on the SQL-side.

I spoke with Laserfiche support: Dynamic fields in the repository must use SQL/Oracle in some way. The two workarounds given were as follows:

1.       Laserfiche Forms – For any documents that have the need for nested fields, the documents can be sent through a business process form in order to collect the metadata and document. From there, those fields can be mapped to repository fields where the information is transferred. In this solution, a user can add options based on the business process options and users will NOT have access to the database. (A forms routing service on the user’s behalf).

 

2.       Laserfiche Workflow – This will be possible but requires a lot of time and work to build out. A rule can be built to trigger through the template fields input and add pattern matching to ensure the fields have the correct format, style, options, etc. Then a query can inputs the data through the DBMS to a SQL table. Depending on the number of fields, the process will have to be split between reading and updating. Reading will require the server service account to interact with SQL but there is no user interaction.

I hope this helps!

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.