Questions
Further investigation of chris21 change detection mechanisms
As part of IDBCHRS-34, the change detection mechanism has been updated such that the user will not be required to select the relevant "EAI Type" field, as this is believed to be too advanced for the goals of Identity Broker v4.0 (in particular, the "Parts" type). These require the user to have full understanding of how chris21 is sending its data back to Identity Broker, down to the position in the string returned, and be able to interpret the result in full.
The mechanism has been updated such that a large majority of forms are completely covered by the changes. However, some forms return change data which cannot be directly mapped back to a chris21 request, such as the ALW form:
cbr="eailst",gw_transactionid="186",eaiidentity="12051411062278000023200000000",eaifile="EMALW",eaichange="A",eaikeydata="OK1006 .79496PAATF00",eaiempno="OK1006",eaiempdate,eailogonid,updatetag="FRONTIER;20514110622",accesslevel="delete",status="ok"
The key for the form is made of 5 components, but things can be of varying lengths. Compare the above key data with:
eaikeydata="101137.79372EABT00"
eaikeydata="100500008790PON_P00"
Under the old mechanism, the user would need to add a Parts type and manually enter the position of the second key in the string in order to use EAI.
Given this complexity, investigate the success of the current changes to change detection for user requirements, further investigate the wrapping of these keys, and also consider alternate change mechanisms to overcome this apparent limitation (such as seeing the impact "Changes enabled" has on file tables).
A dictionary has been added for additional handling of specific forms in the future. Specific forms should be investigated and added to the dictionary.
Customer support service by UserEcho
Add a dictionary of known tables that are like this with their EAI key handling in the interim. If a table fails EAI key extraction, throw an error suggesting that full imports be used.
Moved to v4.1 as the keys can be too complicated and of varying lengths. Updated issue description.
Note that there exists unit tests on ALW form data. These are currently passing for the sake of the build but will need to be updated as this is corrected.
Priority changed to Major as this will be relevant for multiple sites as the chris21 connector continues to increase in exposure. From
SSICT-107andIDBCHRS-47, it may be best to revive the parts mechanism for cases where the key varies due to configuration differences. This should strictly be an advanced setting that should not be required in the majority of cases.Moved to v4.1.1 as this requires Matthew Clark.
I haven't been able to find any documentation of what the "Changes Enabled" setting does, nor been able to see from observation where it logs changes for the file tables.
I have found that there is an "updatetag" field that is on every single row in every single form, which is a combination of the user who made the modification and some number, eg. "updatetag="FRONTIER;40409160909".
The number doesn't seem to be a filetime format that I recognize, but it does change when a user modifies a particular entry. Perhaps this field would produce an alternate form of change detection, although it would not pick up deletes (which are rare in chris21 anyway).
Given my research above, marked as Unassigned
It may be that the Web Services option or chris21 v8 exposes a better mechanism for changes, but I wasn't able to find anything about it
Migrated to VSO.