The Export/Import feature exports content from the portal and imports external content into the portal. Your application is much more site administrator-friendly if users can export/import your application’s assets. For example, if you want to export your application’s assets to use on another installation or you must clear its data but save a copy, you can implement the export feature. Implementing the import feature lets you bring your assets/data back into your application.
Here’s what you’ll learn to do with the Export/Import framework:
- Create Staged Models
- Develop Portlet Data Handlers
- Develop Staged Model Data Handlers
- Provide entity-specific local services for Export/Import framework
- Listen to export/import events
- Initiate new export/import processes programmatically
To track an entity of an application with the Export/Import framework, you must
interface in the app’s model classes. It provides the behavior contract for
entities during the Export/Import and Staging processes. There are two ways to
create staged models for your application’s entities:
Using Service Builder to generate your staged models is the easiest way to
create staged models for your app. You define the necessary columns in your
service.xml file and set the
uuid attribute to
true. Then you run
Service Builder, which generates the required code for your new staged models.
Implementing the necessary staged model logic manually should be done if you don’t want to extend your model with special attributes only required to generate Staging logic (i.e., not needed by your business logic). In this case, you should adapt your business logic to meet the Staging framework’s needs.
See the Developing Staged Models section for more information on the Staged Model architecture.
You must implement Data Handlers to use the Export/Import framework to process LAR files in your application. There are two types of data handlers:
- Portlet Data Handlers
- Staged Model Data Handlers
A Portlet Data Handler imports/exports portlet specific data to a LAR file. These classes query and coordinate between staged model data handlers. They also configure the Export/Import and Staging UI options.
A Staged Model Data Handler supplies information about a staged model (entity) to the Export/Import framework, defining a display name for the UI, deleting an entity, etc. It also exports referenced content.
Visit the Developing Data Handlers section for more information.
When creating data handlers, you must leverage your app’s local services to perform Export/Import and Staging related tasks for its entities. When these frameworks operate on entities (i.e., staged models), it often cannot manage important information from the entity’s local services alone; instead, you’re forced to reinvent basic functionality so the framework can access it. This is caused by services not sharing a common ancestor (i.e., interface or base class).
The Staged Model Repository framework removes this barrier by linking an app’s staged model to a local service.
This lets the Staging framework call a staged model repository independently based on the entity being processed. This gives you access to entity-specific methods tailored specifically for the staged model data you’re handling.
ExportImportLifecycleListener framework is for
listening for certain staging or export/import events (like export successes and
import failures) during the publication process so you can take some action. You
can also listen for processes comprised of many events and take action when
these processes are initiated. For example, you can listen for when
- Staging has started
- A portlet export has failed
- An entity export has succeeded
After an event is triggered, you can take an action like these:
- Print information about the event to your console
- When an import process has completed, clear the cache.
For a complete list of events you can listen for, see
You must extend one of the two Base listener classes:
BaseExportImportLifecycleListener: listens for specific events during a lifecycle. For example, if a layout export fails, you might take some action.
BaseProcessExportImportLifecycleListener: listens for processes during a lifecycle. A process usually consists of many individual events. For example, if a site publication fails, you might take some action. Methods provided by this base class are only run once when the desired process action occurs.
What’s the difference between events and processes?
Events: particular actions that occur during processing (example event
Processes: longer running groups of events (example process listener:
Use the listener type that is most appropriate for your use case.
You can start the process programmatically instead of through the UI. This lets you provide new interfaces or mimic the functionality of these features in your own application.
To initiate an export/import or staging process, you must pass in an
object. This object encapsulates many parameters and settings that are required
while the export/import is running. Having one single object with all your
necessary data makes executing these frameworks quick and easy.
For example, when implementing export, you must call services offered by the
interface. All the methods in this interface require an
ExportImportConfiguration object. You can generate these
configuration objects, so you can easily pass them in your service methods.
There are three factory classes that are useful to create an
ExportImportConfigurationSettingsMapFactory: provides many
buildmethods to create settings maps for various scenarios like importing, exporting, and publishing layouts and portlets. For example, you can reference
ExportImportConfigurationFactory: This factory builds
ExportImportConfigurationobjects used for default local/remote publishing.
ExportImportConfigurationParameterMapFactory: This factory builds parameter maps, which are required during export/import and publishing.
It’s also important to know that
ExportImportConfiguration is a Liferay DXP
entity, similar to
Group. This means that the
ExportImportConfiguration framework offers local and remote services, models,
persistence classes, and more.