I've been working with HFM 11.1.2.4 for over a month now and have been impressed with the improvements in the product. BUT, there is one "improvement" that is not an improvement but a step or five backwards. I'm not saying to not implement 11.1.2.4 - it's a good thing, but this one change isn't a good thing.
For years we've used the HFM Copy Application utility to copy an application from one environment to another. It opens connections to each of the databases and copies the records table by table. Worked great.
With 11.1.2.4, the main focus was to remove the dependencies on Microsoft Windows. That means the Windows utilities went away, including Copy App. What it was replaced with (and that part is good as there were other utilities not replaced, at least not yet) is a new feature in Lifecycle Management that copies an application. It does make sense, as LCM's purpose is to migrate artifacts (things like rules, forms, etc.) from one environment to another. But in practice, it's a step back. LCM writes out to a zipped file on the server that then must be copied over to the other environment and then imported in. This introduces disk I/O three times to the process, compared to zero with the open databases and copy tables/records approach. If an app is really large, you could be waiting and waiting for the huge output file to move around.
Hopefully with time there will be an improvement here later on.
For years we've used the HFM Copy Application utility to copy an application from one environment to another. It opens connections to each of the databases and copies the records table by table. Worked great.
With 11.1.2.4, the main focus was to remove the dependencies on Microsoft Windows. That means the Windows utilities went away, including Copy App. What it was replaced with (and that part is good as there were other utilities not replaced, at least not yet) is a new feature in Lifecycle Management that copies an application. It does make sense, as LCM's purpose is to migrate artifacts (things like rules, forms, etc.) from one environment to another. But in practice, it's a step back. LCM writes out to a zipped file on the server that then must be copied over to the other environment and then imported in. This introduces disk I/O three times to the process, compared to zero with the open databases and copy tables/records approach. If an app is really large, you could be waiting and waiting for the huge output file to move around.
Hopefully with time there will be an improvement here later on.
