LEC Import

This option allows channel structures (with pages; service instances; local groups; XSL files; and references to CSS files, workflows, custom services, users or global groups, and access control)  and content to be imported from a compressed file with the .lec extension (Lumis Exported Channel), located in the “lumisdata/data/exporteddata” directory.

To import a model, it is necessary first to copy the exported file to the “lumisdata/data/exporteddata” directory in the directory structure of the destination portal product. Create the directory for the first import if it does not exist.

Continuing from the previous scenario (in the section Export), we want to import the “Event Agenda” structure under the "Portal" channel. To do this, by right-clicking on the target channel (“Portal”), select the Import option. Next, the following fields must be filled in the following tabs of the import form, allowing the selection of the elements to be imported:

General

1. File: The (.lec) file to be imported. It can be uploaded (if the user is a member of the Portal Administrators) or selected from the available files in Exported Files;
2. Action: The administrator can choose to import as a child channel of the selected channel on right-click (first option), update the selected channel (second option), or import only the content without altering the structure (third option). The second option is used when the channel already exists and needs its structure and/or content updated; the third option is used when only the content is to be updated without affecting the channel structure;
3. Preserve IDs: Allows the migration of the same structure between, for example, development and production servers, maintaining the identity of all objects. When this option is not selected, all channels, services, and pages are registered as new elements in the portal. If this option is not marked and the channel to be imported (or any channel in its tree) has enabled local groups, the corresponding imported channel will have a random prefix for users and local groups. When the import aims at updating a selected channel (second option of the previous field), this option is implicitly assumed. Even for importing a non-existing structure, it is recommended to preserve IDs, considering future updates. When the import is of content only (third option of the previous field), this option is automatically selected and disabled, making it impossible to import content without preserving its ID.
4. Simulate only: Allows the administrator to simulate the import only, viewing in the graphical interface any differences between the channel (source environment) and the destination environment where it will be imported, to check in the report if possible errors regarding the dependencies to be addressed will occur;

5. Existing XSL: Allows choosing the action to be taken in cases of XSL conflict. A conflict occurs when the XSL being imported already exists in the portal, but there are differences regarding the record and/or content of the referenced file (in the case of XSL only, as CSS files are not considered in the import). When a conflict occurs, there is a risk of breaking the layout, either for existing layouts in the portal or for those in the channel being imported, depending on the decision made. Therefore, it is very important to make the correct decision regarding what to do in these cases. This option is not displayed when the selected import is only for content (third option of the Action field);

   The actions can be:

   • Abort import (suggested by default):  In case of conflict, the import is aborted. This option allows conflicts to be manually analyzed and solved, so that the import can proceed again;
   • Update:   this option should be chosen when there is a desire to overwrite existing XSL files and/or records in the current portal;
   • Keep:  this option should be chosen when not  wanting to replace existing XSL files and/or records in the current portal.
6. Include content: Allows determining whether the content of the service instance belonging to the previously exported structure will be imported. The premise for importing contents is that the IDs of the structure must be preserved, so that the references of the contents to the objects are not lost. Therefore, by selecting this content inclusion option, the "Preserve Ids" option is automatically selected. The metadata accompanying the content are also imported (publishing dates, expiration, workflow, among others). During the import process, the contents are reindexed. In any Action chosen, this option is selected by default. When the import is only of content (third option of the Action field), this option is automatically disabled.

Members

Local groups are always imported; however, there are import rules for their members (users and local and global groups and access control). Such rules can be configured, considering that groups or ACLs may or may not exist in the current environment:

1. For new groups or ACLs, one can opt to:

   • Import all members: references to local and global groups and users, as well as their access control, will be imported;
   • Import all group-type members: only references to local or global groups, as well as their access control, will be imported;
   • Import all group-type members ignoring those that do not exist: only references to local or global groups will be imported, along with their access control, ignoring those references that do not exist in the current environment.

   In the case of references to local groups as "member of" another local group, this member import option can be used when these groups are created in other non-exported channels and belong to the access control of the exported channel.

   In the case of references to global groups as "member of" a local group, this member import option can be used when such global groups are not exported along with the structure and do not exist in the current environment.

   • Import only local group-type members: only references to local groups, along with their access control, will be imported.

2. For existing groups or ACLs, one can opt to:

   • Import all members: references to local and global groups and users, as well as their access control, will be imported. In this case, the relationships of the members and their existing references are removed from the current environment during the import;
   • Import all group-type members: only references to local or global groups, as well as their access control, will be imported. In this case, the existing relationships of members that have groups involved and their references are removed from the current environment during the import;
   • Import all group-type members ignoring those that do not exist: only references to local or global groups will be imported, along with their access control, ignoring those references that do not exist in the current environment. In this case, the existing relationships of members that have groups involved and their references are removed from the current environment during the import;
   • Import only local group-type members: only references to local groups, along with their access control, will be imported. In this case, the existing relationships of members that have local groups involved and their references are removed from the current environment during the import.

Some considerations for importing the "Event Agenda" structure:

• Custom workflow “workflow2 ” is already registered in the portal. In the case of the external dependency “workflow2” (custom workflow in the source portal) not being addressed for the import of the “Event Agenda” structure, the import will not be completed due to the absence of both the file and the record in the destination portal, and because it will not be registered automatically during the import. The same applies to custom services;
• External dependencies (channels “Login” and “Templates”, as well as their respective objects) have been exported and imported preserving the IDs, so they are not considered new objects. The same is suggested for the "Event Agenda" structure. Therefore, initially, the import of the “Event Agenda” structure should not present problems, since the relationship between “Event Agenda” and its external dependencies “Login” and “Templates” is maintained.

Based on these considerations regarding the import and considering the scenarios for the "MyDocumentsList.xsl" file and the "Intranet Java" record, the possible outcomes for the import are as follows.

• Once the "Abort import" option is chosen, the import will be aborted when there is any type of conflict between the content of the file or XSL record, or even if the IDs of the records are different.

If no conflicts occur, the import will likely be successful;

• Once the "Keep" option is chosen, the portal will maintain both the XLS file from the current environment (even if it differs in content from the source file) and the record (even if the information regarding the name, description, and path are different from the record in the source environment), as long as the IDs are the same.

The Lumis, in the "Keep" option, treats the XSL differently from the "Abort" and "Update" options because:

1. if the file is different from the exported one and the record does not exist, the record is created and the file is kept;
2. however, if the file does not exist in the current environment and the record is different from the exported one, the record is kept, that is, it maintains the current environment regarding the record and also does nothing regarding the file, meaning the file is not created so as not to compromise the solution.

The import of the XLS will also be successful when there is no file in the current environment and when the IDs of the records are different. Therefore, both the file and the record will be created.

The import will not be successful in the case where the file and its record information are the same as those of the previously exported XLS, and their IDs are different.

• Once the "Update" option is chosen, the portal will update the file and/or the XSL record.

The update will occur in the following cases:

1. The file "intranetJava.xsl" does not exist in the destination (the file will be created) or the content is different (if the ID is the same);
2. The record "Intranet Java" does not exist in the destination or at least one of the record's information is different (if the ID is the same);
3. Both the file and the record do not exist in the destination (the file will be created and the XSL will be registered in the portal) or both are different, respectively in content and in the record information (if the ID is the same).

The import will not occur when the ID of the records are different, in cases 1, 2, and 3.

It is important to pay attention to the alerts in the report about the import, which may include:

• Information about the progress of the import process, regarding the success of the import of the service instance(s) content and the reindexing of the same, represented by the icon:;

• Alerts about updates and maintenance of XSL files represented by the icon:;

• Errors in the import represented by the icon:.  The occurrence of at least one error leads to the cancellation of the import.

• Import completed unsuccessfully also represented by the icon: . Such errors may relate to unaddressed external dependencies; issues between XSL; the channel imported as a subchannel while preserving IDs conflicting with an existing channel due to it having the same IDs as the structure being imported.

• Successful import result represented by the icon: . Upon confirmation, the portal is redirected to the imported channel;