I agree that developers need this information presented in a better way, but I'm thinking the approach would be to have the UI read the Message Map rather than adding properties to the Operation class. Here's my reasoning.
One concern with this idea is that a Business Operation can accept many kinds of request messages. In a sense the Business Operation doesn't actually have a request message at all. It's the individual methods within the Operation that do, and the Message Map specifies how they align.
I suppose the Operation class could have a property for each method-level request class, but that doesn't seem to be very helpful. To make it useful there'd need to be a way to match the properties with their respective methods, such as by naming convention.
Even then, it would just be a form of documentation because the Operation code has no technical need for properties of that kind.
We could certainly rework things so it does use them, but that seems forced and I think it would make things more complicated rather than simpler. For one thing, it would mean that the calling framework needs to set the correct property of the Operation object based on what method it's about to call. Then it needs to clear the reference after the method returns. If you didn't clear the reference it would persist until the next call to that method, in the meantime preventing the request object from being garbage collected. That could cause any number of problems related to resources like locks, network connections, file handles, etc. not being released. You'd have similar bookkeeping for the response message if you moved that to a property.
I'm not sure it's really necessary, but I typically do this after a hosts file change:
I've used this approach before and it generally works fine, but there are some additional things to consider:
1) If your code contains SQL that references tables within the package you're renaming, you need to find/replace the schema as well as the package name. E.g., package my.demo would be schema my_demo. If you don't do this the SQL in your new package will reference the tables in your old package.
2) If you have Persistent classes in your package, you'll likely want to export with the /skipstorage qualifier. That will cause export to omit storage maps, so that the new package gets new storage maps and new globals when you compile. If you don't do this your new package might use the same globals as the old one because find/replace wouldn't change compressed global names like ^package.foobar9876.Class1D.
3) If you follow the previous suggestion, you may run into another problem if you try to copy your old globals to the new ones, so that you're bringing forward your data a well as code into the new package. The issue is that the new storage map will have all properties in the order they're declared. If you've added properties over time to the original class they may be in a different order, making the storage maps incompatible. That happens because new properties are always added at the end of an existing storage map, regardless of where they're declared. That prevents the need to convert data to a new structure if new properties are added to a deployed class. In that case you'll need to manually fix the new storage map by copying forward the old <Value> tags, while retaining the new global references.
Log in or create a new account to continue