I have recently upgraded a 7.11 install to a 16.1 install, and was unable to reu

Certified Lead Developer
I have recently upgraded a 7.11 install to a 16.1 install, and was unable to reuse my configuration repository. I've been able to reuse that same repository from 7.9 through to 7.11, but doing so for 16.1 resulted in various errors (such as Exception: ObjectNotFoundException[SYSTEM_RECORD_TYPE_USER]), despite applying the (very few) changes recorded in the documentation.

My main concern was with the changes in the web.xml file; there are quite a few new items in the new version (com.appiancorp.common.logging.ConfigureLog4j, com.appiancorp.rdbms.datasource.BusinessDataSourceValidator, com.appiancorp.applications.BundledApplicationsLoader for example), and simply inserting the new web.xml into the old repository does not work.

I understand that the way around this is to create a new repository, then merge my changes from the old repository into the new one, but that seems to rather defeat the object of...

repositories.zip

OriginalPostID-191179

OriginalPostID-191179

  Discussion posts and replies are publicly visible

  • 0
    Certified Lead Developer
    ... a repository.

    Additionally, I don't see the additions to web.xml documented in the release notes - ultimately, I'd like to know what changes in the 16.1 repository mean it's no longer possible to use the 7.11 repository. I've attached a zip file containing both the 7.11 and 16.1 repositories.
  • There are changes to custom.properties in the way you define the DATASOURCE. Its documented under release notes. Have you had a look into that?
  • 0
    Certified Lead Developer
    Yes, I read the release notes and implemented the required changes. They did not affect the errors I was seeing when using the 7.11 repository.

    Whilst I was there, I noticed that the recommended JNDI naming had changed from java:jdbc/MyDatasource to jdbc/MyDatasource - though that, again, was not the issue. I assume the java: was redundant anyway.
  • Reusing a repository created with the configure script after updating Appian is not a documented or supported procedure. I'm actually quite surprised to hear this worked for you in the past. The idea of the repository isn't to carry configurations over across updates; it is to act as a change management tool for a given build of Appian and also facilitates setting up Appian in tandem with the configure script. The files within a repository may well need to be updated as improvements are made to Appian. Your best bet is to follow the documentation whenever you update Appian.
  • 0
    Certified Lead Developer
    @Eliot, I think we'd all be better off if you (Appian) did look at supporting the repos as a tool to use across migrations. Some of us have some fairly complex installations to support, and putting together the repos are non-trivial.

    I, like Phil, was able to use the same repo across 7.9, .10, and .11, which was very helpful. At a very minimum, tracking the config repo deltas in release notes like you do for the config file changes would be a start.
  • That feedback is good to hear and I will definitely pass it along to the team.

    If possible, it would be helpful if you could elaborate a bit more on which aspects of updating Appian you find to be particularly challenging. I can certainly appreciate that many of our customers have fairly complex installations, but it would help to have more specific details about what you feel makes your configurations "non-trivial" to set up. Of the 19 steps listed in the documentation: forum.appian.com/.../Upgrade_Guide.html , where do you see yourself potentially encountering difficulties due to the complexity of your installation?
  • 0
    Certified Lead Developer
    @Jim Agreed. Whilst "high-level" changes are documented, there are certainly background changes that aren't. Granted, we're talking super low-level - even internal architectural - changes here that only some server administrators would be interested in, but it would definitely be useful to have visibility of such changes.

    @Eliot I'm surprised that you're surprised! Given the fact that the repository mostly contains *configuration* changes, it should - by its very nature - be relatively portable. Of course, every now and then certain configuration options might get deprecated (I'm referring to recent change, like deprecating an engine), but otherwise I don't see why a previous - in this case, a single version older - repository shouldn't be a starting point rather than something to be discarded.

    Anyway, my main concern are the as yet undocumented changes to the web.xml file. Are you able to shed any like on the new item in that file?
  • 0
    Certified Lead Developer
    @Eliot, The structural problem with that upgrade document is that in reality you're performing steps 9,10,11,12 before step 5 when using a config repo. And step 5 becomes a loaded step in the process. I've been around long enough that I know that this doc was written before the config repo, or before even ACM was made a public tool, so it was designed for folks who are doing the upgrade manually. In my experience, it just doesn't match reality. I'll be happy to discuss more offline.
  • philb, as you say, configurations can change between builds. What needs to be configured and how it needs to be configured may change as new features are added and improvements are made. For example, authentication can now be configured through the admin console, so it is no longer necessary to maintain custom security configuration files when updating.

    Accordingly, simply copying files over en masse may not always be effective, even though it sounds like you've had some success doing so in the past. The idea of having the repository be a "starting point" for carrying configurations over is an interesting one, but my understanding is that this is not the intended use of the repository at this time.

    The documentation addresses the configuration changes that need to be made when updating Appian and provides details on which files need to be modified or moved. If you find that things are missing from the documentation or aren't clear enough, please continue to let us know. Again, we are always looking to improve and I really appreciate the insight you've provided into your experience with updates. It's definitely given me some ideas.

    jims419, thank you as well for your feedback. I'd be glad to hear your thoughts in more detail offline and I'll reach out to you separately.