Posts tagged "solutions"

Using Lists and Conditions in Correspondence Management to create complex template rules

The Correspondence Management Solution presents unique concepts of List and Condition assets (aka modules), to enable advanced correspondence template design. These asset types allow defining rules for content inclusion, that may be quite complex by using a combination of (nested) Lists and Conditions.

Lists

Lists are a great way to group content, i.e. Texts, Images, nested Lists and Conditions (read on, if you are new to Conditions) together into logical groups. For instance, when you wish to mandate the inclusion of a Text paragraph A with Text paragraph B, you could create List, and include Texts A and B within the List, marking them as mandatory content.

Apart from this, you could also set advanced Styles on Lists, so as to specify if and how the content should be bulleted or numbered, set indentation on individual content, and much more. You could also specify advanced rules for the List to control whether the List can accept more content than what is originally assigned to it (during correspondence creation), or whether content within it can be re-ordered, and so on.

Visit the official document to see how to work with Lists using the List Editor.

 

Conditions

Conditions are a great way to specify inclusion rules of content within a correspondence. One could define expressions on control variables (placeholders and/or Data Dictionary elements), such that appropriate content may be selected into the correspondence,  based on runtime values of these variables. Content may be Texts, Images, Lists or Conditions (thereby allowing deeply nested conditions).

Conditions are defined similar to SWITCH-CASE statements. Each expression has a result content associated with it. The first expression that evaluates to TRUE is chosen as the result and the content associated with it is included in the final correspondence.

Note that you can choose to return multiple content against an expression by wrapping (grouping) them within a List and then select the List as the result of that expression.

Visit the official document to see how to work with Conditions using the Condition Editor.

 

As you can see, Lists can be included within other Lists or Conditions and vice-versa. Thus allowing users to create complex rules for their templates, optionally combined with styles.

Customizing ADEP Solutions – simplified!

Here are some critical aspects that contribute greatly towards the ease of customization of Adobe’s Customer Experience Management (CEM) Solutions.

No EAR deployments and Application server overheads!

The fact that the CEM solutions sit over the OSGi framework (the Apache Felix OSGi container), has completely changed the way they are built and deployed. As compared to the conventional application server model, where one would typically deploy an EAR file, restart the server and wait for an awful long time for the complete server startup, the OSGi model and the new platform brings in the capability to deploy artifacts (bundles and packages) at runtime, without having to bounce the entire server (which anyway is much, much faster). If at all, there may be cases where you would have to restart the OSGi bundles, but that’s a piece of cake given that you have a sophisticated console to do this from, within a few seconds.

Simplified UI changes – Great separation of concerns!

The UI components of all CEM solutions are based on what is known as the Experience Oriented (XOA) architecture. These UI components are popularly known as UX Components, which by definition is a combination of MXML and ActionScript classes that is bundled into SWC files that separate concerns and encapsulate each concern behind an interface. Interfaces make the implementation of concerns (i.e. presentation, domain, etc.) replaceable and extensible. The Presentation layer of each component, further has the separation of a HostComponent and the Skin, such that one can change the UI look-and-feel (for example, re-ordering of UI elements) by simply modifying the Skin of that component, without having to worry about the overall presentation logic (which lies in the HostComponent). Similarly, the component’s Styles are externalized into CSS files, such that one can change the themes, colors, fonts, etc. by simply changing these CSS files. This allows changes to the solutions while still retaining supportability. Apart from these, other enhanced customizations may involve changes to the HostComponents or the Domain layer, as per the desired use case.

Apart from these, the overall development model around customizations on the UI layer, takes-away the overhead of making changes in various different projects. One can now just add the necessary customized artifacts (MXML, Actionscript, CSS, etc.) to the Solution Template projects itself and override the default implementations via CSS definitions and/or standard inheritance. To learn more, refer to this sample scenario from the Correspondence Management solution.

CRX as the Content repository – Ease of debugging!

The solution assets are now stored in CRX, which provides an Apache Jackrabbit based content repository. The nice and intuitive Content Explorer allows an easy way to navigate across the repository to search for your assets (that are clearly visible as nodes, by their names). Users can select an asset or one of its child nodes to see/investigate the properties associated with the asset. One can also download asset content by selecting an asset and clicking on the data property of that asset (for example, for a Layout asset in CM, it is the filexdp property on the layout node). This greatly helps in debugging/troubleshooting assets within the system.

Apart from this, there is also the CRXDE Lite interface that enables you to perform standard development tasks from the browser.

Check out the links to some of these common interfaces in ADEP,  that you would need frequently during development.

OSGi Services – Possibility of isolated server-side customizations!

Since services deployed in the container are classic OSGi services, one can choose to build/deploy his/her own service as a separate OSGi bundle. Thus, allowing clear separation of custom services vs. the out-of-the-box ones.

Great overall Development Platform!

The Adobe Digital Enterprise Platform (ADEP) offers great tools to support development with ADEP Experience Services. The tools include a set of additional extensions for Flash Builder and a rich SDK (Flex, Java, Mobile) for building applications. The Experience Services SDK is an Experience Package distributed and downloadable using Adobe Package Share.

Overall, since the solutions are built on top of the Adobe Digital Enterprise Platform, they leverage these great capabilities of the platform itself, such that one can build custom applications around it that solves one or more end-to-end use cases.

Comprehensive Help Content!

The solutions publish comprehensive documentation around the usage of the solution, steps to customize areas within the solution, sample customization scenarios, etc. – all of which are a great set of resources to learn about the solution and provide helpful starting points/references for customizations. These learning resources keep evolving as more features are added to the solution, and more scenarios are identified. So, keep an eye on them!

 

Postprocessing your correspondence

Correspondences created in enterprises would typically have to be integrated to a back-end process for further distribution (via email, fax, print), document processing (apply digital signatures, encryption, etc.) or archival of the correspondence.

The Adobe Correspondence Management solution provides a convenient way to achieve this by leveraging orchestrations/processes on the ADEP Document Services platform for defining the back-end process (that can use one or more Document Services, based on the enterprise requirements), and providing the ability to easily bind them to a given correspondence template.

Read more about creating a postprocess for the CM solution on the Document Server.

Once such processes are created on the Document Server, can then be mapped to a Letter template in the  Postprocess drop down of the Letter Template Editor (as shown below), where the available postprocesses (as defined on the Document Server) are listed:

 

 

 

 

 

 

 

Tip: If you create a new process, with an existing Manage Assets UI session opened, your process will not be listed in the Postprocesses dropdown until you relaunch or refresh (F5) the Manage Assets browser window (or open the Manage Assets UI in a new browser window).

When the correspondence creation is complete (using the Create Correspondence UI), users can Submit the correspondence (see snapshot below indicating the Submit button), which invokes the associated/mapped postprocess for that Letter template, with the final correspondence PDF and XML data (used to generate the PDF). The postprocess, which would be an orchestration, can then act upon the document (PDF) as necessary.

 

Solutions and the Application Context

Solutions over ADEP have introduced the concept of an application context (aka app context), which can be seen as a unique identifier, that various server side modules use to identify the execution context (from the current execution thread) and process requests in context of that solution. For instance, when persisting content/assets onto the CRX repository, the platform’s persistence module (official known as Platform Content) uses the current (invoking) app context to determine where to store the content/assets, and what configurations to use (which would typically be different for different solutions). See snapshot below, indicating the solution specific content areas.

Note that the storage location is /content/apps/cm for Correspondence Management, and /content/apps/icr for Integrated Content Review, which happen to be the app contexts for the two solutions.

Since it is essential for the server to identify the execution context, if you do not set or establish the application context before you make calls to the solution APIs, you will encounter a server error that says :  “Unable to fetch application context“. To set the app context, use one of the two methods:

App context in your Flex application

If you are invoking a solution API from a flex application, ensure that you set the app context using:


var appToken:AsyncToken = com.adobe.ep.ux.content.services.search.lccontent.LCCQueryServiceFactory.getInstance().setAppContextService("/content/apps/cm"); // setting app context for the CM solution
appToken.addResponder(new mx.rpc.Responder(<your success handler>, <your fault handler>));

App context in your Java application

If you are invoking a solution API from a java based application, ensure that you set the app context using:

com.adobe.livecycle.content.appcontext.AppContextManager.setCurrentAppContext("/content/apps/cm"); // setting app context for the CM solution

 

The app context concept is also used (or rather leveraged) in other scenarios such as driving solution specific Building Block (BB) configurations. Since a Building Block is meant to be reusable across solutions, it exposes certain configurations that can be different for different solutions. Hence, the BB needs to behave differently depending upon the context in which it is being used or invoked. Below is an example where the Data Dictionary BB is used by two solutions – CM and ICR – and has configurations specific to each solution, lying within the solution’s specific app context - /apps/cm for CM and /apps/icr for ICR.

Publishing assets in the Correspondence Management Solution 3.0

The Correspondence Management Solution 3.0 introduces the concept of publishing assets, and deprecates the concept of activation (which was used in the 2.5.x version of the solution).

The solution is typically configured on two separate (ADEP Experience Server) instances – an Author instance and a Publish instance (see the installation and configuration documentation on how to configure the solution over the two instances).

The Author instance is one on which assets/templates are created and managed (using the Manage Assets interface). One can also Preview the Letter templates created on the Author instance, which launches the Create Correspondence interface in a document preview mode.

The Publish instance is one on which the final correspondence is created by agents (using the Create Correspondence interface), using the designed letter templates and published assets. The Manage Assets interface is also available on this instance, but with restricted actions.

Once done with the asset authoring, they must be marked Ready to Publish, indicating the same to the persona (which would typically be different from the one creating/editing the asset) responsible for publishing the asset, who can then go ahead and publish the asset. Note that when publishing an asset, all assets related to this asset should be in Published or Ready To Publish state. Assets that are in Ready To Publish state are published automatically, while the ones that are already Published, are ignored. If any related asset is in a Modified state, the publish operation is aborted, and hence cannot proceed until all related assets are marked Ready to Publish. The understanding behind this behavior is that there could be different persona involved in creation of various related assets, and it is essential that each one of them marks the respective asset ready to publish (indicating completion) before they can really be published.

Here’s a state diagram for various asset states, and how they transition on various actions:

On publishing an asset, a new version of the asset gets created on the Author instance, and the asset is immediately ‘replicated’ over to the Publish instance, which always has a single (head) version of an asset.

Also note that any related Data dictionaries are not published automatically when assets that use it are published. You are required to explicitly publish data dictionaries.

Read more on asset publishing and versioning here.

ADEP Solutions and Document Server

The Adobe Digital Enterprise Platform consists of two technology stacks – the Experience Server and the Document Server. The combined architecture provides services required for various Customer Experience Solutions.

The Experience Server needs to be integrated (configured) with the Document Services to leverage services that address multiple enterprise applications requirements around content creation, management, protection, distribution and enterprise workflows. The below video not only shows the steps to configure your Document Server instance with your Experience server, but also talks about building web applications that use Document Services.

 

 

You may also check out the published documentation on the exact steps to be performed.