LiveCycle Doc team

The LiveCycle ES Update 1 (8.2) installation includes Assembler IVS, which is a great tool for testing DDX expressions without having to modify a Workbench ES process. The tool also includes some nice examples that illustrate different DDX concepts such as assembling a document, disassembling a document by bookmarks and pages, and converting a PDF document to PDF/A.

Assembler IVS is also a good way to validate your installation as described in the blog entry
Validating a LiveCycle Install posted on the LiveCycle Product Blog. In fact, IVS is an acronym for Installation Verification Sample.

Before you can use Assembler IVS, you must deploy it to your application server.

Deploying Assembler IVS

On the JBoss application server, deploy Assembler IVS by copying the adobe-assembler-ivs.ear file from the
[InstallLocation]\deploy folder to the [InstallLocation]\jboss\server\all\deploy folder.

If you are using another type of application server, you must also restart your application server.

Using Assembler IVS

After you deploy Assembler IVS to your application servicer, bring up its user interface in a browser by navigating to this URL
http://[server_name:port_name]/Assembler

Here is a screenshot of the Assembler IVS user interface.

Here are the general steps for testing a DDX expression:

1. Specify the DDX by copying your DDX expression into the large window. Or you can use one of the DDX expressions available by clicking DDX or Demos at the top of the window.
2. Specify the input files by clicking the "+" button near the Collateral panel. The interface presents a field that lets you browse for the file. Click this button for each file being used as collateral.
3. Specify the input map by clicking the "+" button near the Input Map panel. If needed, modify the names of the map entries to match source names in your DDX expression. Click this button for each entry in the document map.
4. Associate the input files with map entries by dragging files down onto one of the input map entries. You can use the same file multiple times with different input map entries. You can also place multiple input files in the same input map entry.
5. Invoke Assembler IVS by clicking Invoke .

If Assembler IVS succeeds in creating a result PDF document, it displays the result in a new browser
window. If it is unsuccessful, it provides feedback on the error.

Posted by Kathy Stone at 8:00 AM | Permalink | Comments (0)

Have you ever sat at your desk thinking, now wouldn’t it be great if they thought to put in a feature that did “x” or “y”? Well here’s your chance to speak up!

The Adobe Reader team is eliciting feedback from you. They would like to know what you want to see most in the next few versions of Adobe Reader. Take the survey at the link below, it should take you about 5 minutes.

Adobe Reader Survey

Posted by Tasmina Patel at 10:58 AM | Permalink | Comments (0)

You can use the Assembler service to combine multiple documents into a PDF Portfolio that specifies how a viewer application’s user interface presents collections of file attachments. When your process or application invokes Assembler, it provides a Document Description XML (DDX) that describes the PDF Portfolio you want to produce. This article describes different types of PDF Portfolios and the DDX expressions you can use to produce them.

This article addresses the following types of PDF Portfolios:

Simple: A collection of files, each of which is defined only by the basic information in the file specification (for example, file name, size, MIME type, and creation date). Adobe® Reader® 8.0 and Adobe Acrobat® 8.0 introduced support for this feature. (See Creating a simple PDF Portfolio .)

Augmented file descriptions: Same as a simple PDF Portfolio with the addition that each file is described with additional information. Viewing applications can use the additional information to sort or identify the files in the portfolio. The syntax of the addition information is specified in a schema that is included in the PDF Portfolio. Adobe Reader 8.0 and Acrobat 8.0 introduced support for this feature. (See Creating a PDF Portfolio with augmented file descriptions .)

Aggregated PDF Portfolios: A collection of files that are assembled from other PDF Portfolios that omit layouts (self-contained user interface for navigating the file sin the collection). The files in those source PDF Portfolios are included with their augmented file descriptions (if present). (See Creating PDF Portfolios aggregated from other PDF Portfolios.)

Contains its own user interface: A more complex or dynamic PDF Portfolio can include a PDF Portfolio Layout (a self-contained user interface for navigating the files in the collection). Adobe Reader 9.0 and Acrobat 9.0 introduced support for this feature. Assembler cannot yet create PDF Portfolios that include PDF Portfolio Layouts, nor can it create PDF Packages that group the collection contents into a folder hierarchy; however, it can add files to existing PDF Portfolio with these characteristics. (See Creating a PDF Portfolio that contains its own user interface.)

For a definition of the terms PDF Package, PDF Portfolio, and PDF Portfolio Layout, see PDF Packages vs. PDF Portfolios, which is located in the December 2008 archive of this blog. For information about the attributes that comprise a PDF Portfolio, see ISO 32000-1:2008 - Document management -- Portable document format.

Creating a simple PDF Portfolio

Here is a DDX example that creates a PDF Portfolio that contains a cover sheet and two component files. If the cover sheet is not a PDF file, Assembler attempts to convert the file to PDF. You can omit the cover sheet, in which case Assembler provides a default cover sheet for you.

This DDX example omits a schema, which means that (assuming doc2 is not a PDF Portfolio) the component files are described by only the standard file specification information (file name, creation date, MIME type, and size). Although the PDF files in a PDF Collection may contain metadata (for example Author, Title, Keyword, and Creating Application), the Acrobat user interface for PDF Collections does not use this information to describe component files.

<DDX xmlns="http://ns.adobe.com/DDX/1.0/">
    <PDF result="outDoc" >
        <PDF source="doc1" bookmarkTitle="Cover"/>
        <PackageFiles source="doc2" required="false">
            <File filename="MyFirstFile.pdf" 
                   mimetype="application/pdf"/>
        </PackageFiles>
        <PackageFiles source="doc3" required="false">
            <File filename="MySecondFile.txt" 
                   mimetype="text/plain"/>
        </PackageFiles>
        <PackageFiles source="doc4" required="false">
            <File filename="MyCollection.pdf" 
                   mimetype="application/pdf"/>
        </PackageFiles>
    </PDF>
</DDX>

The files specified in the PackageFiles elements can be ordinary PDF documents, other PDF Portfolios, or other file formats:

• PDF files. When the result PDF Portfolio is viewed in the Acrobat list layout, users see a thumbnail of these files. Any of the component PDF Portfolios can be opened in a separate window.
• PDF Portfolios. Same as ordinary PDF files except users see a thumbnail of the cover sheets for the component PDF Portfolios. These files can be opened in a separate window.
• Other file formats. Assembler does not convert non-PDF documents into PDF. Rather it leaves such files in their unaltered state. These files can be opened in a separate window provided an application is available that supports the file format.

Creating a PDF Portfolio with augmented file descriptions

Here is a DDX example that creates a PDF Portfolio that contains a cover sheet, two files that contain augmented descriptions, and a schema that describes the non-standard attributes that can be associated with each file in the portfolio. (The standard attributes are those specified in the file specification.) In addition, the package specification can include elements that specify display order, sort order, and target locale, as described in the DDX Reference.

<DDX xmlns="http://ns.adobe.com/DDX/1.0/">
    <PDF result="outDoc" initialView="firstPage">
        <Package>
            <Schema>
                <Field name="Name" type="Text"/>
                <Field name="Animal" type="Text"/>
                <Field name="Breed" type="Text"/>
                <Field name="Color" type="Text"/>
                <Field name="Gender" type="Text"/>
                <Field name="Age" type="Number"/>
                <Field name="Altered" type="Text"/>
                <Field name="Location" type="Number"/>
                <Field name="File Name" type="Filename"/>
            </Schema>
        </Package>
        <PDF source="cover" bookmarkTitle="Cover"/>
        <PackageFiles source="shasta" required="false">
            <File filename="Shasta.pdf" mimetype="application/pdf"/>
            <FieldData name="Name">Shasta</FieldData>
            <FieldData name="Animal">Dog</FieldData>
            <FieldData name="Breed">Keeshond</FieldData>
            <FieldData name="Color">Grey</FieldData>
            <FieldData name="Gender">Male</FieldData>
            <FieldData name="Age">10</FieldData>
            <FieldData name="Altered">Yes</FieldData>
            <FieldData name="Location">95070</FieldData>
        </PackageFiles>
        <PackageFiles source="sam" required="false">
            <File filename="Sam.pdf" mimetype="application/pdf"/>
            <FieldData name="Name">Sam</FieldData>
            <FieldData name="Animal">Dog</FieldData>
            <FieldData name="Breed">Grayhound</FieldData>
            <FieldData name="Color">Grey</FieldData>
            <FieldData name="Gender">Male</FieldData>
            <FieldData name="Age">8</FieldData>
            <FieldData name="Altered">Yes</FieldData>
            <FieldData name="Location">95070</FieldData>
        </PackageFiles>
    </PDF>
      <InitialViewProfile name="firstPage" openToPage="1" 
             show="BookmarksPanel" magnification="FitPage" />
</DDX>

The following screen shot shows the appearance of the schema information in the Acrobat 9 list view of the PDF Portfolio produced by the above DDX example. Notice that each entry in the schema is presented with a column for corresponding values created by the PackageFiles element.

Notice that the Filename field appears in the schema but that the files' PackageFile element do not provide a corresponding value. That's because Acrobat obtains the values for this field from the file specifications for the component files. Including Filename in the schema ensures that file name appears in the Acrobat list view.

PDF documents contain PDF metadata such as Author, Title, Keyword, and Creating Application. Currently, Assembly does not provide any mechanism for accessing this data, not even as process data. This means that it is not possible to use DDX to create a PDF Portfolio that includes the PDF document's metadata in the user interface; however, you may be able to use JavaScript to generate a DDX file that creates such a PDF Portfolio.

Creating a PDF Portfolio aggregated from other PDF Portfolios

Here is a DDX example that creates a PDF Portfolio assembled from a cover sheet and two PDF source elements. If either of the source elements contains a PDF Portfolio, Assembler adds the following items from those portfolios to the resulting PDF Portfolio:

• Component files
• Schemas (if present) aggregated into a new schema.

<DDX xmlns="http://ns.adobe.com/DDX/1.0/">
    <PDF result="outDoc" initialView="firstPage">
        <PDF source="cover" bookmarkTitle="Cover"/>
        <PackageFiles>
          <PDF source="collection1" required="false" />
          <PDF source="collection2" required="false" />
       </PackageFiles>
   </PDF>
   <InitialViewProfile name="firstPage" openToPage="1" 
     show="BookmarksPanel" magnification="FitPage" />
</DDX>

For example, if collection1 is a PDF Portfolio that specifies the following schema definition:

<Package>
    <Schema>
        <Field name="Name" type="Text"/>
        <Field name="Animal" type="Text"/>
        <Field name="Breed" type="Text"/>
        <Field name="Color" type="Text"/>
        <Field name="Gender" type="Text"/>
        <Field name="Age" type="Number"/>
    </Schema>
</Package>

And collection2 is also a PDF Portfolio that specifies the following schema definition:

<Package>
    <Schema>
        <Field name="Name" type="Text"/>
        <Field name="Animal" type="Text"/>
        <Field name="Altered" type="Text"/>
        <Field name="Location" type="Number"/>
        <Field name="File Name" type="Filename"/>
    </Schema>
</Package>

Then the schema in the resulting PDF Portfolio will be:

<Package>
    <Schema>
        <Field name="Name" type="Text"/>
        <Field name="Animal" type="Text"/>
        <Field name="Breed" type="Text"/>
        <Field name="Color" type="Text"/>
        <Field name="Gender" type="Text"/>
        <Field name="Age" type="Number"/>
        <Field name="Altered" type="Text"/>
        <Field name="Location" type="Number"/>
        <Field name="File Name" type="Filename"/>
    </Schema>
</Package>

The screen shot shows the appearance of the resulting PDF Portfolio when viewed in Acrobat list view. Notice that the view shows fields that indicate the schemas from both component PDF Portfolio are combined. Also notice that the cover page in the result is a 3-page document that includes the cover page from the cover document and the cover pages from collection1 and collection2.

Creating a PDF Portfolio that contains its own user interface

Assembler can add component files and schemas to a PDF Portfolio that already includes a PDF Portfolio Layouts, but it cannot create original PDF Portfolios that include such layouts.

Here is a DDX example that adds a new document to the PDF Portfolio provided in the PDF source element. If the PDF source element contains a PDF Portfolio that includes a PDF Portfolio Layout, then the result also contains the PDF Portfolio Layout.

<DDX xmlns="http://ns.adobe.com/DDX/1.0/">
  <PDF result="outDoc" >
    <PDF source="myPortfolioWithLayout"/>
    <PackageFiles source="doc2" required="false">
      <File filename="MySecondFile.txt" mimetype="text/plain"/>
    </PackageFiles>
  </PDF>
</DDX>

If the layout in the PDF source document supports schemas (augmented file descriptions), the files you add should specify values for those fields, as shown in this DDX example:

<DDX xmlns="http://ns.adobe.com/DDX/1.0/">
  <PDF result="outDoc" >
    <PDF source="myPortfolioWithLayout"/>
    <PackageFiles source="harry" required="false">
      <File filename="Harry.jpg" mimetype="image/jpeg"/>
      <FieldData name="Name">Harry</FieldData>
      <FieldData name="Animal">Dog</FieldData>
      <FieldData name="Breed">Saint Bernard</FieldData>
      <FieldData name="Color">Tan and white</FieldData>
      <FieldData name="Gender">Male</FieldData>
      <FieldData name="Age">8</FieldData>
      <FieldData name="Altered">Yes</FieldData>
      <FieldData name="Location">44202</FieldData>
    </PackageFiles>
  </PDF>
</DDX>

Using the following DDX example with PDF Portfolios that contain layouts yields unpredictable results.

<DDX xmlns="http://ns.adobe.com/DDX/1.0/">
    <PDF result="outDoc" initialView="firstPage">
        <PDF source="myPortfolioWithLayout" />
        <PackageFiles>
          <PDF source="collection1" required="false" />
          <PDF source="collection2" required="false" />
       </PackageFiles>
   </PDF>
  <InitialViewProfile name="firstPage" openToPage="1" 
    show="BookmarksPanel" magnification="FitPage" />
</DDX>

For more information

For a complete description on DDX, see DDX Reference.

For instructions on creating a certified PDF Portfolio, see Certifying PDF Portfolios, which is located in the December 2008 archive of this blog.

For an introduction to PDF Portfolios, see the PDFDevJunkie blog on the Adobe Acrobat Developer site.

Posted by Kathy Stone at 4:00 PM | Permalink | Comments (1)

You can add common layout and background elements to a form design using master pages. A form design is the design-time version of a form that you create in LiveCycle Designer ES. By default, all new form designs have a master page, which is applied to the first page. Any page that you add to the form design is formatted according to the layout of the default master page unless you create and apply different master pages to other pages.

At the very least, master pages can define the orientation and dimensions of pages. For example, you can create one master page for portrait orientation and a second master page for landscape orientation. In more complex forms, you can use master pages to adjust the size and position of content areas, add page numbering, company logos, and create single- or double-sided features (such as headers and footers).

Example of a form that uses master pages
The following form is a Dunning Notice. It has a flowable layout where the data in the table flows onto the second page. In this design, the first page of the form is different from second page. If enough additional data were added to the table, it would flow onto a third page, and the new page would have the same layout and background elements as the second page. The Dunning Notice form shown here was designed with two master pages, one for the first page only and one for subsequent pages.

The first master page displays the company logo, form title, watermark, address box, and footer. The second master page is for subsequent pages. It displays the same watermark, address box, and footer as the first master page plus page numbering. Here is what the master page layout for the Dunning Notice form looks like:

To learn more about creating master pages in LiveCycle Designer ES, go to the LiveCycle Designer ES Help and search for "Using master pages".

Posted by Ginette Thibault at 3:03 PM | Permalink | Comments (0)

This article assumes that you have some knowledge of programming concepts and are familiar with web services and LiveCycle Remoting. For information about using web services and LiveCycle Remoting, see "Invoking LiveCycle ES Using LiveCycle Remoting" and "Invoking LiveCycle ES Using Web Services" in Programming with LiveCycle. The Backup and Restore service lets you put LiveCycle ES into backup mode, which enables hot backups to be performed. Hot backups permit you to backup the LiveCycle server while it is running, eliminating any downtime. The Backup and Restore service does not actually perform a backup of LiveCycle ES or restore your system. Instead, it puts your server in a state that enables you to perform consistent and reliable backups while your server continues to run. You are responsible for backing up the Global Document Storage (GDS) and the database connected to the LiveCycle ES server. The GDS is a directory used to store files, such as files used with long-lived processes.

As an administrator, you can use the LiveCycle Administration Console to put LiveCycle ES into backup mode. You can also programmatically put LiveCycle ES into backup mode using the Java API and web services, but because the Backup and Restore service cannot be used in a process created using Workbench ES, it cannot be invoked using LiveCycle Remoting as described in Programming with LiveCycle ES. To invoke the Backup and Restore service using LiveCycle Remoting, you must invoke the service directly. You may want to invoke the Backup and Restore service programmatically because you want to build software applications for backing up your server.

The trick to invoking a service directly using LiveCycle Remoting is to know the name of the service and the string values to refer to types, methods, and properties. To determine the string values, you can look at the WSDL on the server by referring to the WSDL by its name. (See the table at Invoking LiveCycle ES Using APIs > Invoking LiveCycle ES using Web Services). For example, to use the Backup and Restore service, you type the following in a web browser:

http://localhost:8080/soap/services/BackupService?wsdl&lc_version=8.2.1

From returned WSDL, you can then determine the string names of the types, methods, and properties to use as values for accessing the remote objects for your ActionScript and MXML code. Alternatively, you can also determine the values to use by stepping through accessed objects using the debugger in Flex Builder and see the results from the ResultEvent.result property.

This blog entry, describes how to write ActionScript and MXML code to invoke the Backup and Restore service using LiveCycle Remoting to do the following tasks:

• Enter backup mode.
• Leave backup mode.

Entering Backup mode

You enter backup mode to allow for hot backups of a LiveCycle ES server. When you enter backup mode, you specify the following information based on your organization's backup procedures:

• A unique label to identify the backup mode session that may be useful for your backup processes


• The time for the backup procedure to complete


• A flag to indicate whether to be in continuous backup mode, which is useful only if you are performing rolling backups. Rolling backups is a way to provide continous backups, which means that a new backup mode session is initiated as soon as the previous session is complete.

Before you write applications to enter into backup mode, it is recommended that you understand the backup procedures that will be used after you put the LiveCycle ES server in backup mode. For more information about considerations when performing backups for LiveCycle ES, see Administering LiveCycle ES.

Steps to enter backup mode using LiveCycle Remoting

To enter backup mode by using LiveCycle Remoting, perform the following tasks:

1. Include necessary files in your development project. These files are important to include in your project for compiling your code properly and using the Backup and Restore Service API.
   
   
   Include the adobe-remoting-provider.swc file that enables you to perform remoting. (See "Invoking LiveCycle ES Using LiveCycle Remoting" in
   Programming with LiveCycle ES.)
   
   
   
   


2. Create a BackupService client object to use the Backup and Restore Service API.




• Create an mx:RemoteObject instance through either ActionScript or MXML. Associate it with the name assigned to the remoting endpoint for the Backup and Restore service. You can see the name of the service in Applications and Services in LiveCycle Administration Console. (See Applications and Services Administration Help
  .)


• Configure the enterBackupMode method using the mx:method tag that belongs to the
  mx:RemoteObject tag.


• Create a ChannelSet object by using its constructor for connecting to the LiveCycle ES server and add a channel by invoking the ChannelSet object `s addChannel method and passing an AMFChannel object that specifies a unique ID and a URL that includes the default remoting URL, such as http://localhost:8080/remoting/messagebroker/amf, for a local instance of the LiveCycle ES server.


• Specify the LiveCycle ES user name and password by invoking the mx:RemoteObject instance's
  setCredentials method and passing the following values:




• A string value that specifies the user name.


• A string value that specifies the corresponding password value.


• Attach the ChannelSet object to the mx:RemoteObject instance by assigning the
  ChannelSet object to the mx:RemoteObject instance's channelSet data member.
  
  
  
  




3. Before you enter backup mode, determine a unique label, the amount of time that you want to allocate to perform the backup, and whether you want the LiveCycle ES server to stay in backup mode. These considerations are important to integrate with the backup procedures established by your organization. (See
   Administering LiveCycle ES
   .)
   
   
   
   For example, if you are writing a Flex application, you may want to get the parameters for performing the backup based on input from a user.
   
   
   
   
4. Enter backup mode with the parameters that are consistent with the backup procedures at your organization. For each of the required parameters that includes the label, time to perform the time-out, and whether to be in continuous backup mode:
   
   
   
   




• Create an Object instance that stores the input parameter that the Backup and Restore Service API enterBackupMode operation requires. For each input parameter, assign the parameter to the
  Object instance by using the following syntax:params["aLabel"] = "BackupTimeLabel"
  


where param is the name of the Object instance that stores parameter values. In this situation, aLabel stores the name of the label that is passed to the Backup and Restore service.


You specify label, backup time, and whether to keep the server in continuous backup mode by using
aLabel, aBackupModeTimeout, and aContinuousCoverageMode respectively, as keys for the parameters. You specify the following information for each of the values that you determined from step 3:



• aLabel: A string value that that specifies a unique human-readable label that identifies the backup mode session. It is recommended that you do not use spaces or characters that cannot be encoded into XML format.


• aBackupModeTimeout: An integer value that specifies the number of minutes to stay in backup mode. You can specify a value from 1 to 10080(one week).


• aContinuousCoverageMode: A Boolean value that specifies whether to be in continous backup mode. A value of True specifies to be in continuous backup mode. Continous backup mode means that a new backup mode session will be started after the current one is completed. A value of False means that continous backup mode is not used and after leaving backup mode, the purging of files from the GDS resumes.





Note: You can determine the strings to use by accessing the WSDL and looking at the input parameters for the enterBackupMode method.

5. Enter backup mode by calling the mx:RemoteObject instance's enterBackupMode method and passing the Object instance that stores the input parameter values.


6. After you enter backup mode, you can retrieve information about the session. The information that you can retrieve after you enter backup mode may be useful for integrating with your backup procedures. For example, the label, backup ID, and start time may be useful as input for filenames for your backup procedure.
   
   
   
   




• Within the main MXML file, create a BackupModeEntryResult instance by using its constructor. You can create a BackupModeEntryResultobject from a custom ActionScript class that you create. The class contains properties that are returned. The names must correspond to the names in the BackupModeEntryResult object.


• Using the ResultEvent.result property by using the index that contains the result. For the Backup and Restore Service API, the result is accessed using the BackupModeEntryResult as a key which provides an Object object that you coerce to the BackupModeEntryResult instance you created.


• Retrieve each value using the names of the properties you defined in the BackupModeEntryResult
  object you created and use them accordingly as input or parameters for your backup procedures.


• You can determine the names to provide to each property in the ActionScript class you create by accessing the web service using a tool such as .NET Webservice WebStudio, or you can debug in Flex Builder and see the results from the ResultEvent.result.





7. After you successfully enter backup mode, you can perform a backup of the Global Document Storage (GDS) and the database that the LiveCycle ES server is connected to. This step is specific to your organization, since you can perform this step manually or youcan run other tools to perform the backup procedure.
   
   
   
   Backup the Global Document Storage (GDS) and the database which your LiveCycle ES server is connected to. The actions to perform the backup are not part of the LiveCycle ES SDK and may even include manual steps specific to the backup procedures in your organization.

Example code: Entering Backup mode using LiveCycle Remoting.

• Click here to view the main MXML to enter backup mode.


• Click here view the BackupModeEntryResult class.

Leaving backup mode using LiveCycle Remoting

You leave backup mode to resume normal operation of the LiveCycle ES server.

Steps to leave backup mode by using LiveCycle Remoting

1. Include necessary files in your development project. These files are important to include in your project for compiling your code properly and using the Backup and Restore Service API.

   Include the adobe-remoting-provider.swc file that enables you to perform remoting. (See "Invoking LiveCycle ES Using LiveCycle Remoting" in Programming with LiveCycle ES .)

2. Create a BackupService client object to use the Backup and Restore Service API.

You do not use a BackupService client API object directly in LiveCycle Remoting. Instead, you create a RemoteObject instance and specify the method to invoke on the LiveCycle ES server. To use the Backup and Restore Service API in LiveCycle Remoting, perform these steps:




• Create an mx:RemoteObjectinstance through either ActionScript or MXML. Associate it with the name assigned to the remoting endpoint for the Backup and Restore service. This step allows you to use the Backup and Restore Service API client object using LiveCycle Remoting. You can see the name of the service using Applications and Services in LiveCycle Administration Console. (See
  Applications and Services Administration Help
  .)


• Configure the RemoteObject instance to use the leaveBackupMode method using the
  mx:method tag nested below the mx:RemoteObject tag.


• Create a ChannelSet object by using its constructor for connecting to the LiveCycle ES server. Add a channel by using the ChannelSet object `s addChannel method and passing an
  AMFChannel object that specifies a unique ID for the channel, and a URL that includes the default remoting URL, such as http://localhost:8080/remoting/messagebroker/amf, for a local instance of the LiveCycle ES server.


• Specify the LiveCycle ES user name and password by invoking the mx:RemoteObject instance's
  setCredentials method and passing the following values:




• A String value that specifies the user name.


• A String value that specifies the corresponding password value.




• Attach the ChannelSet object to the mx:RemoteObject instance by assigning the
  ChannelSet object to the mx:RemoteObject instance's channelSet data member.
  
  
  
  



3. Leave backup mode by calling the mx:RemoteObject instance's leaveBackupMode method.
   
   
   
   
4. Retrieve information about the operation to verify that it was successful.



Within the main MXML file, create a BackupModeResult instance by using its constructor. You can create a BackupModeResult object, which is created from a custom ActionScript class that you create. The class contains properties that are returned. The names must correspond to the names in the
BackupModeResult object.




• Using the ResultEvent object's result property by using the index that contains the result. For the Backup and Restore Service API, the result is accessed using the success as a key which provides an Object instance that you coerce to the BackupModeResult instance you created.


• Retrieve the backup mode identifier using the id property that was defined in the BackupModeResult object you created.




Note:You can determine the name of the property in the ActionScript class you create by accessing the web service using a tool such as .NET Webservice WebStudio, or when you debug in Flex Builder and see the results from the ResultEventobject's result
property.

Example code: Leaving Backup mode using LiveCycle Remoting.

• Click here to view the main MXML to leave backup mode.


• Click here view the BackupModeResult class.

Posted by Gilbert Yu at 11:06 AM | Permalink | Comments (0)

You know those notes that can be added to tasks using Workspace ES? (If you don’t, you can take a look at Working with notes and attachments). The Workbench ES help explains how to retrieve those notes as a document value after the form is submitted, but (believe it or not) the help leaves out a few details about how to reference the information in those notes.

Notes have a title and a body (the text of the note) which you may want to extract and use in the process. As explained in the Document attributes for attachments and notes topic in Workbench ES Help, when a file or a note is attached to a task, a document value is created to represent the attachment or note. You use document attributes in XPath expressions to access information about the attachment or note.

The topic in the Workbench ES help did a pretty good job of describing how the attributes are used for attachments, but not so good for notes. Here are the attributes to use to access note titles and body text:

wsfilename: The note title
wsdescription: The note text

For example, a process creates emails from notes that are attached to tasks - the note title is used as the email subject, and the note body text is used as the email body. The notes and attachments of the task are saved in a list variable named attachmentVar. For a document value that represents a note, the following XPath expressions evaluate to the title of the note and the note’s body:
getDocAttribute(/process_data/attachmentVar[1],"wsfilename")
getDocAttribute(/process_data/attachmentVar[1],"wsdescription")

Don’t forget to first determine whether the document value represents an attachment or a note. You use the wsattachtype attribute to do that.

The following process uses the Set Value service to determine whether the document is a note, and if it is a note it uses the Set Value service again to extract the note title and body, and then uses the Email service to create the email message (click the image to see a larger view).

This process only checks one item in the task’s document list. A more robust process would use a loop to check all of the documents.

Posted by Scott Brodersen at 2:59 PM | Permalink | Comments (0)