Best Practice for Developing with LiveCycle Workbench ES2 – Application Structure, Iteration and Transition

Author: JianJun Jiao
Editor: Suhas Kakkadasam Sridhara Yogin

Customers using LiveCycle Workbench to develop solutions will have the following requirements:
Note: To differentiate a customer’s LiveCycle application with an application in Workbench, we take “project” as customers’ LiveCycle application.

1. Three environments (DEV – for development of LiveCycle applications, TEST – for testing the developed LiveCycle Applications, PRODUCTION – for deploying and using LiveCycle applications.);
– Project could be transferred to cross environments smoothly.

2. Multiple active development streams aka. parallel development with different developer roles;
– Roles could be process developer, form developer, Flex developer, schema developer and so on;

3. An iterative development style;
– Project could be handed over for testing or production while development of later versions can continue.

LiveCycle Workbench ES2 provides necessary fundamental functionality so that these development requirements can be met. The new development model in LiveCycle ES2 is application centric rather than repository centric that was used in previous versions.

Here is a general solution:

1. Use multiple structured applications for parallel development and resource management;
2. Make use of application versions for iterations;
3. Use LiveCycle archives for transitions;

Here is an application structure sample:

 

 

 

 

 

 

In LiveCycle ES, all processes, forms and other assets are stored in a flat structure called repository. But in LiveCycle ES2, application is used to manage resources which are called application assets. A LiveCycle application is simply and logically a container of assets during design-time.

In LiveCycle Workbench ES2, it’s suggested several applications be used to better manage the project resources. It’s to say one project could have several LiveCycle applications in Workbench.

For the sample application structure above, it has some advantages:

  1. Categorize different type of assets in different applications. Forms and processes could be put in different applications. Thus, the project is more logical and administrable. Subsequently, multiple developers of different roles can work more effectively on the project in parallel.
  2. Some resources say fragments and schemas are categorized together so they can be better reused.
  3. Reduce the impact scope when developers do some operations say deployment/undeployment applications.
  4. Better support the parallel development. Generally, the more applications the team used, the less team members would affect each other.
  5. It leads to better performance. It takes much more time to do operations say synchronize/deploy on one application with a big account of assets. That’s to say, the performance thus degradates a lot on a large application. For LiveCycle ES2, it’s recommended the count of assets in one application should be less than 50.

In LiveCycle Workbench ES2, every application version is composed by a major version and a minor version. For every application asset, it has revisions. LiveCycle developers can make use of these versions for iterations or even releases. Generally, a release could be a combination of different versions of applications.

Talking to transitions between development, testing and production environment, LiveCycle archives can be used. In Workbench, you can create an archive for each application; or, you can create an archive for all applications of your project. These archives then can be imported to other environments.

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 3.0/10 (2 votes cast)
Best Practice for Developing with LiveCycle Workbench ES2 – Application Structure, Iteration and Transition, 3.0 out of 10 based on 2 ratings
This entry was posted in Adobe LiveCycle ES2 (9.0.x) and tagged , , , , , , , , . Bookmark the permalink.

19 Responses to Best Practice for Developing with LiveCycle Workbench ES2 – Application Structure, Iteration and Transition

  1. c@tc.se says:

    Hi mjiao,

    Thanks for your post. I’d be interested in hearing about best practises regarding maintaining conformance on dev, test and prod regarding versions of assets. It would be nice to be able to track versions of individual forms, e.g. Form.xdp version 1.13, between different environments.

    Also, what can you tell us about best practises regarding keeping multiple versions of the same application available? My experience is that we need to start each version of an application in descending order to have them published simultaneously. Obviously, there’s a better approach.

    • mjiao says:

      Thanks for your comment and questions.

      We must use application versions to track individual assets. Application assets say forms don’t have versions in LiveCycle Workbench ES2 which is different from LiveCycle Workbench ES, but as you know, the application these assets belong to can have versions. Although application assets have revisions, a revision is not equal to a version since every check-in will create a new revision. To better differentiate different revisions of assets or assets in application versions, we can utilize the properties of the assets. Add descriptions to your assets before you check in them so that you can know the difference when you view the history of the assets.

      Regarding keeping multiple versions of the same application available, could you tell more details on which issues or confutions you have? I’m still writing some best practices on other topics, such as references, better parallel development. You input is appreciated.

  2. Szymon Piadlowski says:

    Hi.
    We have similar organization of Forms in our project, however we findout that if we put “common” form fragments into one App and forms into another then if we create new version of Form App then “Internal error” runs. In debug console we can see that Livecycle is searching for framents in Forms App directories which is kind of negation of common resources between applications. Have you ever had this kind of problems??
    Here is case:
    /Applications/Fragments App/1.0/Fragment.xdp
    /Applications/Forms App/1.0/Form.xdp
    Form.xdp has relationship to Fragment.xdp
    We try to create /Applications/Fragments App/2.0 and then it runs Internal Error.

    Any suggestions??

    • Mark Jiao says:

      I tested your case in Workbench ES2 but didn’t meet any issue. It’s likely a performance issue. “For LiveCycle ES2, it’s recommended the count of assets in one application should be less than 50.” If your application size is too large, you’re likely to encounter such issues like “internal error”. So the suggestion is that you divide a large application to some small applications. Besides, some quick fixes have been delievered in ES2.5 for these issues.

  3. Jan Kropiwnicki says:

    Hi Mark,

    Let me put some more details about our case, so you can replicate the issue. Unfortunately it is happening even for small amount of resources.

    Currently let’s assume that we have two applications:

    AppForm 1.0
    AppFragment 1.0

    in AppForm we have folder called ‘forms’ and there ‘Form.pdf’. This is sample PDF form with one button, field and fragment relation.
    in AppFragment we have folder called ‘fragments’ and there ‘Fragment.xdp’.

    Fragment.xdp is just a fragment containing sample image linked (not embed) with reference ‘.\logo.jpg’, where logo.jpg is also located under \AppFragment\1.0\fragments\ path.

    Fragment is referenced from Form.pdf as ‘..\..\..\AppFragment\1.0\fragments\Fragment.xdp’ which is fine, it points path to another application with fragment.

    Let’s assume that I want to create new version of AppForm to implement new business requirements for PDF form. What I do is create new application
    version of AppForm – 1.1.

    Both applications are not deployed but fully checked in.

    Now I try to create new version of AppForm and when I click Finish I get ‘Internal Server error’ pop up.

    In a debug console I can see info:

    ALC-DSC-000-000: com.adobe.livecycle.design.client.DesigntimeServiceException: Internal error.
    at com.adobe.livecycle.design.service.commands.TLOCommand.getMembers(TLOCommand.java:226)

    !ENTRY com.adobe.livecycle.workbench.applicationview 4 0 2011-06-06 09:20:02.671
    !MESSAGE Workbench Command Exception
    !STACK 0
    java.lang.NullPointerException
    at com.adobe.livecycle.workbench.applicationview.handlers.SynchronizeHandler.synchFilesInFolder(SynchronizeHandler.java:504)
    at com.adobe.livecycle.workbench.applicationview.handlers.SynchronizeHandler.synchronize(SynchronizeHandler.java:300)

    !MESSAGE Error in creating application version
    !STACK 0
    ALC-DSC-000-000: com.adobe.livecycle.design.client.DesigntimeServiceException: Internal error.
    at com.adobe.livecycle.design.service.commands.CreateApplicationVersionCommand.execute(CreateApplicationVersionCommand.java:127)

    Caused by: com.adobe.repository.bindings.dsc.client.ResourceRepositoryClientException: ALC-REP-018-000: Resource [/Applications/AppForm/1.1/1.0/fragments/Fragment.xdp] does not exist or you do not have sufficient rights to access it.
    at com.adobe.repository.bindings.dsc.client.ResourceRepositoryClient.createRelationship(ResourceRepositoryClient.java:188)
    at com.adobe.livecycle.design.service.commands.CreateApplicationVersionCommand.copyFileRelationships(CreateApplicationVersionCommand.java:176)

    !ENTRY com.adobe.livecycle.workbench.applicationview 4 0 2011-06-06 09:26:24.421
    !MESSAGE New ApplicationVersion Wizard exception
    !STACK 1
    com.adobe.livecycle.application.ApplicationException: Failed to create application version.
    at com.adobe.livecycle.application.manager.ApplicationManager.createApplicationVersion(ApplicationManager.java:631)
    at com.adobe.livecycle.workbench.applicationview.wizard.NewApplicationVersionWizard$1.execute(NewApplicationVersionWizard.java:153)

    This error indicates that something appears to be broken while creating new version of application that has relationships to other applications as XDP fragments.

    We’re using recent version of Workbench ES2.5: 9.5.0.0.20100908.1.247189

    Please let me know if you have experienced this kind of issue and how to solve that? Any help would be greatly appreciated.

    If you will provide me your e-mail I can send you application LCA so you can see the issue exists.

    Thanks,
    Jan Kropiwnicki

    • Mark Jiao says:

      Jan, thanks for the detailed information. I believe your issue is not a performance problem but might be a bug or an environment issue.

      I have tried to reproduce it in my Workbench ES2.5 and LiveCycle server ES2.5 but couldn’t see any error.

      I found there was a error point in the log you attached: the relative reference path was not processed correctly.
      [/Applications/AppForm/1.1/1.0/fragments/Fragment.xdp] does not exist or you do not have sufficient rights to access it.

      But the reference is correct as you checked in the form.
      Fragment is referenced from Form.pdf as ‘..\..\..\AppFragment\1.0\fragments\Fragment.xdp’.

      So the following suggestion is that check your environment (server version) to make sure you was connecting Workbench ES2.5 to LiveCycle ES2.5. If you still have the problem after that, you have to contact Adobe support to get more information on the issue in your evironment (they can file the bug and deliver the quick fix to you later).

      You can send your LCA to mjiao@adobe.com. At least I can test whether your application has the same problem in my environment.

  4. Jan Kropiwnicki says:

    Mark,

    Thank you for your reply, I will follow up via email and hopefully we’ll together find a solution.

    Your help is greatly appreciated.

    Thanks,
    Jan Kropiwnicki

  5. John Nesbitt says:

    Mark,

    FYI – we experienced the exact same issue as Jan Kropiwnicki when trying to create a new version of an application where forms in the application referred to fragments in another application.

    Posting the solution or workaround here would be handy.

    Thanks,
    John.

  6. Mark Jiao says:

    I’ve got the LCA from Jan but failed again to reproduce it in my test environment which has same version of Workbench and LiveCycle server. As agreed in the email, Jan will find Adobe enterprise support so that engineering team could understand the situation more. Thanks.

  7. Jan Kropiwnicki says:

    John,

    I have already reached Adobe enterprise support and as soon as I will be able to provide solution or will get more info about an issue I will let you know, most probable by posting an answer here.

    Thanks,
    Jan Kropiwnicki

    • Mark Jiao says:

      With more information from Jan Kropiwnicki in the email session, I’ve reproduce the “version creation failure” in a fresh installed LiveCycle ES2.5 server and Workbench 9.5.

      Good news is that if the following quick fixes for LC ES2.5 and Workbench 9.5 have been installed and deployed, this issue is gone. The environment that I used to reproduce the issue but failed has applied these quick fixes. https://www.adobe.com/cfusion/entitlement/index.cfm?e=lces2_sp2

      Jan Kropiwnicki will apply the quick fixes to their system. Let’s wait the update.

      • Mark Jiao says:

        A specifix quick fix for this issue has been posted. Please contact Adobe support to get it. (Thanks Jan for the information)

  8. Andrew Phillips says:

    With regards to versioning an application I would like to know what is the best practice for the following. If I have a long lived process with a couple of short lived sub processes inside my application and a new customer requirement comes that requires a modification to the schema of the form and a change to the short lived processes, I would go ahead and version my application so now I have version 1.0 and 1.1. I make the changes to the schema and the short lived processes in version 1.1 and deploy the new application version. Version 1.0 and 1.1 of the long lived process will now start to use all the version 1.1 short lived sub processes, but what happens if the modifications I made to the short lived processes will only work in the 1.1 version of the application and not the 1.0 version. Is there any way to tell the 1.0 version to continue using the 1.0 short lived processes.

    • Mark Jiao says:

      Are your long-lived process and short-lived processes in the same application? From your statements, I think the anwser is yes. If so, when you create a new version of your application, version 1.0 of the long lived process still use the version 1.0 short lived sub processes. The creation of a new version 1.1 won’t affect your assets and their references in version 1.0.

      • Andrew Phillips says:

        Yes my long-lived process and short-lived processes are in the same application. I just ran a process recording on the same short-lived process in version 1.0 and version 1.1 and when the short-lived process is being called from the 1.0 long-lived process the 1.1 short-lived process version is being called and not the 1.0 version. So is there anyway to force is to use the 1.0 short-lived process? It seems like my only option is to rename all my short-lived processes in the 1.1 application version so they are different then the 1.0 application version.

        • Mark Jiao says:

          I’ve found the root problem: this is a design-time issue which doesn’t affect the run-time.
          1. The version 1.1 long-lived process indeed uses version 1.1 short live-process in run-time;
          2. the actual issue is that it opens the wrong sub processes in version 1.0 when you select “Open Subprocess” in the version 1.1 long-lived process. (You can move the mouse pointer to hover over the title of the sub-process you opened from the main process to see the full path. Then you know which version of the process you opened.)

          If you want to verify the run-time, follow this:
          1. create a new application – MyAppTest;
          2. create a new short-lived process in MyAppTest/1.0;
          3. create a new long-lived process in MyAppTest/1.0 and add a sub-process in it to use the short-lived process;
          4. check in and deploy the MyAppTest/1.0;
          5. Start recording on the two processes;
          6. create a new version of MyAppTest/1.0; deploy it;
          7 . Start recording on the two processes on MyAppTest/1.1;
          8. invoke the long-lived process in MyAppTest/1.1 and check which version of short-lived process is recorded.
          (I tested it Workbench 9.0 and 9.5, the short-lived process in version 1.1 is recorded so it indicates the rum-time is correct)

          If you need a quick fix, please contact Adobe support.

          • Jan Kropiwnicki says:

            Hi Mark,

            Do you know the reference id or patch version that Adobe has covered above issue.

            We are also facing same problem during design time and would like to have updated Workbench ES2.5 to fix this issue.

            Please let me know if you have more info about that or should I contact directly support.

            Thanks,
            Jan Kropiwnicki

  9. matt says:

    What roles do you give to your different developer groups?

  10. Elly says:

    Thanks for this post, its very interesting!