Submitted by Rinku Hazarika, Software AG
Known Issues
Integration Server cannot migrate the metadata setting of CentraSite
Reason: Migration utility does not migrate the metadata setting of centrasite.
Resolution: Reconfigure the setting after migration.
Folder <oldServerPath>/IntegrationServer/packages/WmPRT/ns/ recreated on each IS startup after upgrade
Reason: After migration some of IS config file still contains the source IS directory value.
Resolution: Before migration apply fix. For target release 90 - IS_9.0_SP1_Migration_Fix1 or latest.
And for 95 - IS_9.5_SP1_Migration_Fix1 or latest.
While migrating from 8.2 to 9.7 using sbs on the same host, we see that some watt settings are different in the 9.7 IS. Some watt settings have been incorrectly migrated
Reason: Migration utility does migrated some of watt setting, instead of preserving the watt values of source in target after migration, it’s just overwrite with default one.
Resolution: Before migration install the fix 9.7 - IS_9.7_Migration_Fix1 or latest . 9.8 - IS_9.8_Migration_Fix1 or latest.
Limitation
IS cross platform migration failed with error “Migration - Passman migrator:Error in passman migration... com.wm.passman.PasswordSanityException: BAP.0100.00009 Cannot retrieve password after failed sanity check ”
Reason: Password storage format may changes from one platform to another so in that case migration utility can leads into circumstances like cannot retrieve password after failed sanity check.
Resolution: Find out the encoding type in the source IS. Lets say, the encoding type in the source was ISO8859_1 then perform the following steps:
Option 1:
- Add the export statement as the first line in the migrate.sh
- “export JAVA_TOOL_OPTIONS=-Dfile.encoding=ISO8859_1”
Option 2: - Open a command prompt on the Target Machine
- Run : export JAVA_TOOL_OPTIONS=-Dfile.encoding=ISO8859_1
- Now run migrate.sh from same command window
Exception during attempt to register Trigger. Error message is getting written into IS while registering the triggers “2015-02-13 10:56:22 CST ISS.0098.0055E Exception during attempt to register Trigger: om.wm.app.b2b.server.dispatcher.exceptions.InvalidDocumentException: ISS.0098.9006 No matching Document Type exists”
Reason: This error appears when the package containing triggers get loaded before loading the package which contains the doc.
Resolution: Put the dependency between the packages which contains the doc and trigger in such a way that packages which contains the doc get loaded before the package which contains triggers.
Error occurs when try to generate WSD on wm9.5 using wsdl that was export from wm7.x
Resolution: Following steps should help in resolving this issue:
1. Edit “server_95.cnf” file
2. Set "watt.server.SOAP.warnOnPartValidation=true"
3. Redo --> generate WSD on wm9.5 using wsdl that export from wm7.x(Upload_created in 7.x soaprpc.wsdl) again via Designer 9.5.
Question & Answer
Custom service that is used for DataStore cache enabled option in service level properties was not working as it was working in 8.2 on wM9.7
Question: After upgrade from version 8.2 to 9.7 with fix level IS_9.7_Core_Fix2. A custom service that is used for DataStore cache enabled option in service level properties was not working as it was working in 8.2 on wM9.7 but there were only few transaction that are getting proceed by wM 9.7 about 30-40% only when sent 500 transaction at once. When we made the cache enabled option to be false on the service level it proceed all the transaction but slower than expected.
Answer: Check if caches service’s output is modified by some other flow. Flow services were modifying the output document returned by cached service. If this is the problem, you can try the steps below and see if it helps.
Please note that customer can modify <IS_DIR>/config/Caching/SoftwareAG-IS-Services.xml, add following lines in ServiceResults cache.
copyOnWrite="true"
copyOnRead="true"
i.e.
<cache
name="ServiceResults"
eternal="true"
maxEntriesLocalHeap="1000"
maxElementsOnDisk="1000"
copyOnWrite="true"
copyOnRead="true"
cacheLoaderTimeoutMillis="30000">
<persistence
strategy="none"/>
</cache>
Migration of Public Certificates. Certificates are not getting migrated from 7.1.3 to 9.5. using migration utility
Question: After using migration utility, only the server level private key (../config/certs/keys) and ca certs (../config/certs/ca) are migrated to wM 95 IS but not the public certs (../config/certs/public) being migrated to wM 95 IS.
Answer: The behavior of security certificates is changed between IS version 713 and IS 9.5. In IS 713, we needed to provide the paths of actual certificates files in the security configuration in IS Admin (eg: <dir>\abc.der). When these certificates are migrated to IS 9.5, the certificates combination of (PrivateKey, PublicKey, CA Key) get converted into one Keystore File placed at location: <ISDir>\config\security\keystore. Name of the keystore file is same as that of the absolute path of PrivateKey certificate (eg: softwareag95_integrationserver_packages_migration_sec_localhostpk_ks_config)
Also, all the public certificates which were present in: “Trusted Certificate Directory” in IS 713 > IS Admin>Security>Certificates would be converted to a Truststore file after migrating to IS 9.5.
This Truststore file (also in .jks format) would contain all the public certificates present in that directory.
WebService Changes confirmation
Question:
WSDL Post migration from 7.x to 9.7
1. Whether namespace are changed post 9.7 migration?
2. Whether element names are changed post 9.7 migration?
3. Whether order of elements is changed post 9.7 migration?
4. What is the summary of changes in WebService WSDL file post 9.7 migrations?
5. Whether WSDL generation post element change (addition/deletion) in 9.7 will retain 7.x WSDL definition?
6. What are the changes we need to apply or remove to retain 7.x WSDL definition or remove 7.x WSDL definition in Designer or server config properties?
7. What is the impact of having legacy WSDL generation properties in server config files? Whether it impacts generating WSDL in 9.7 fasion?
Answer: There have been several changes in IS web services between 7.x and 9.7 Web services, including entirely replacing the web services stack used by IS in the 8.2 release and forward. But every attempt has been made to retain full runtime compatibility for existing 7.x web services within a 8.x or 9.x IS runtime.
WSDL is a definition of a web service. Any existing IS 7.x web service should continue to run in a 9.7 IS as long as the pre 82 compatibility mode is set to true for the WSD and it was truly created in a 7.x environment. A newly created IS web service in the IS 9.7 system, will make use of the new web services stack while exposing all of enhanced support, such as ws-policy based ws-security, ws-addressing support, ws-reliable messaging support, enhanced XML support, etc.
The main area of change which has caused some migration issues in the 7.x to later relases, is that while IS 7.x depended on the fact that XML namespaces are only able to be represented within IS document types that containing fields with the prefix:localname and the actual XMnamespace value being contained within the XML namespace property of the field, the 7.x system did not enforce that limitation and in some instances could map namespace qualified XML elements into non-prefixed IS document type fields.
In the 9.7 IS, the usage of XMLnamespaces is limited to IS document type fields whose name uses the prefix:localName format and that limitation is enforced during WSD creation and WSDL generation.
But again, even that enforcement of prefix usage can be bypassed for IS web service definitions created in the 7.x release and migrated to the 8.x or 9.x releases after applying the current 9.7 fixes and making use of the watt parms enabling the incorrect 7.x behavior. The latest correction to the backward compatibility for a 7.x WSD and prefix mapping has been addressed in the IS_9.7_Core_Fix4 fix.
If the 7.x web services are properly making use of the prefix:localname format of the IS fields within a document type, the watt parm settings should not be are not required at all for backward runtime compatibility. It should be supported automatically.
One other enhancement to the namespace usage available in the 9.7 release that was not available in the 7.x release is the ability to specify a user defined prefix to be associated with any specific namespace URL during WSDL consumption and IS document type generation. Which helps to ensure that newly created Is document types can use a specific prefix for XMLnamespace names allowing more consistent IS document type generation.
In summary, an existing IS web service that is currently running in an IS 7.x environment should continue to run unchanged in the 9.7 environment.
Changes to document types used by IS 7.x web services should not affect the Namespace usage or WSDL generation, other than to reflect the actual structural changes of those document types for the 7.x created WSD.
To make use of the new 9.x features will require at a minimum to set the pre 8.2 compatibility mode to false for the WSD, which will then issue warnings for any changes occurring by making the compatibility mode change, or by deleting the existing 7.x WSD and creating a new 9.x WSD.
To see a full list of web service enhancements made from 7.x to 9.7 someone would have to create a consolidated list of changes by reading the 8.2, 9.0, 9.5, 9.6 and 9.7 release notes.
To my knowledge there is no single place to see all changes between 7.x and 9.7.
Arrays in WSDL with document/literal in WM 9.7
Question: After migrating package from 7.1.2 to 9.7, the Arrays in WSD provider in WM IS 9.7 not working as earlier. And webservice set with Pre-8.2 compatibility mode to true.
When channels send SOAP request with "anonymous" namespace then WM IS interprets document structure as “ArrayofrepaymentPlanItem” and which causes the schema validation errors and also unable to process the request as document structure changed. But this same SOAP request works fine when we point back to “7.1.x” instance.
Answer: From wM v9 onwards, it has been made strict with namespace and prefixes. Meaning, if you have a namespace defined, then it must have an associated prefix and vice versa. If there is no namespace or prefix then there is no issue, but if it has one then you must adhere to the implementation.
In 9.0, 9.5, 9.6, 9.7 & 9.8 the IS has tightened its requirement about using prefixes with document type field names if they are to be namespace qualified fields. Actually it is only adding validation of the limitation that was designed into the 7.1 release, but never enforced allowing some unexpected behaviors in earlier releases.
But the policy of requiring a prefix for namespace qualified fields only applies to the IS document type field names and IS documents for use while converting to/from XML instances, not to the XML instances themselves.
If they are referring to as an “anonymous” namespace, is not anonymous at all. It is an XML namespace qualified element. It is namespace qualified by making use of the an XML construct called “default namespace”. That default namespace (declared by an xmlns=blahblahblah attribute) then becomes associated with every non-prefixed element within scope from that point forward. Basically any child element(s) of the one declaring a default namespace, and also descending down into any children of the child element(s).
In an XML instance every element is either associated with an XML namespace or not. Whether the assignment of a namespace comes from using a default namespace (xmlns=blahblahblah) and an non prefixed name or by using an xmlns:prefix=blahblahblah and the prefix:name format of the elements should not matter at all. An XML element is either namespace qualified or not, and the IS code needs to retain that namespace association within the IS. The currently supported manner to retain a namespace association with an IS field is through the use of the prefix:name format of IS field names in IS document types. The underlying IData implementation used by IS documents is simply not XML namespace aware.
The tightening of the restriction in the 9.0 release was simply to begin enforcing the use of prefixes within those document types used by IS web services to ensure correct conversion to/from IData->XMLinstance by doc type directed conversion which is used by IS web Services.
The issue is further complicated by the fact that for IS 8.0, the manner in which the IS represented “xxxList” fields (arrays) within IS documents used by IS web services was changed. Prior to 8.0, the doc/literal repeating fields were handled in much the same manner as RPC\Encoded arrays. That was with a “wrapper element” containing named xxxItem elements. As of 8.0 and higher, the handling of xxxList fields within Doc/lit was adjusted to no longer make use of the array wrapper fields and to simply use a much more normal approach of repeating fields within the XML instance.
Long IS restart issue because of WSDs pointing to wrong host
Question: IS take long time to startup.
Answer:
Performed below steps for all WSDs in the custom packages which was taking time to load.
1. Changed the invalid remote host and port mentioned for include/import schema and all other occurrences in node.ndf file of the WSD with the host port values present in its associated Port Alias from IS Admin web Services
2. Reloaded the package