This basically comes down to RRTFM (ReRead The FM) on my part. The problem is self-inflicted. The passwords in the EIE:DataExchange records are changing when we manually change the Verify Process Status field from 1 to NULL.
We were having a problem with a DE validation getting stuck when there were mapping issues and we could not rerun the validation because the button was still set to Get Results. After a little reverse engineering I unhid the Verify Process Status field so we could clear it and Validate the DE again (yes I know the field is hidden for a reason but it is test and is how I learn the modules inside and out). Armed with this info I returned to the AIE manual to see what it says about the verify button and found this: "If the AIE service crashes for any reason after you click the Get Result button, you must explicitly log out of your BMC Remedy User session using the Logout button on the Data Exchanges Console. If you simply close and restart your BMC Remedy User session, the Verify button continues to show the Get Result label, preventing you from verifying other data exchanges." It was enough to help me find the AL 'EIE:ST-ClickLogoutButton' (Push Fields action to 3 fields on EIE:DataExchange) which resets the Verify button when clicking the Close button. I find statement in the AIE manual misleading because you need to click the button labeled Close (the db name is Logout but an end user would not know that). Actually closing the "Remedy User session" as suggested (Closing WUT, going to logout.jsp or PERFORM-ACTION-EXIT-APP) will not reset the Verify flag. I don't find it intuitive that a person needs to close the form to reset the Verify status. Especially when it is just and AL behind a button. It looks like it may have been an after thought something like "hey there is already an AL for closing the window let's tack it on to that to reset." I think this is a common decision Remedy developers come up against. Try and keep objects to a minimum for performance and manageability or add the necessary fields/workflow to make the UI intuitive and function like "normal" web or complied apps where you have traditional code (although there is something to be said about code bloat in other types of apps too). It also seems odd that the push fields action to reset the Verify status has a 1=1 qualification so it will reset all Data Exchanges. I don't think it would cause any harm but say if two people were working on different Data Exchanges at the same time one user's actions would have an effect on the other user. It seems like a odd session bleed over to me. I hope these details help others who try to be smarter than the system :) Jason On Fri, May 7, 2010 at 11:18 AM, Jason Miller <jason.mil...@gmail.com>wrote: > We have Atrium Core 7.6 patch 1 on our test server (we just patched > yesterday to try and resolve this). We are experiencing an issue where Data > Exchanges stop working after working on other Data Exchanges. We see the > following errors in the AIE logs and can see the failure in aruser.log. > > [Thu May 06 2010 11:26:47.4910] - <TID: 001> <ERR > Error (623): > Authentication failed > [Thu May 06 2010 11:26:47.4910] - <TID: 001> <ERR > InitCMDBConnection - > cannot access AR System server:ITSM76APPSERVER. Error = 2 > [Thu May 06 2010 11:26:47.4910] - <TID: 001> <ERR > StartDataHandlers: > CMDB Data Handler failed to start. > > Logging workflow I see where an AL pulls the current credentials from > EIE:ApplicationSettings and passes those to aiexfer.exe correctly. It seems > that somewhere within the aiexfer.exe process it uses the credentials from > the EIE:DataExchange record. These records appear to get out of sync as > other Data Exchanges are being worked on. I unhid the fields on > EIE:DataExchange to try and manually correct the password. This triggers > workflow and changes the hash. I found that it works fine setting the > passwords in the db. > > As a temporary workaround I created a stored procedure that does the > following and put it behind a button so I don’t need to go into the db each > time the person managing the Data Exchanges starts seeing errors. > > UPDATE T710 --EIE:DataExchange > SET > C102 = 'pw1', --Admin Password > C15185 = 'pw2, --Encrypted Password > C536871114 = 'pw3' --Admin PasswordN > WHERE C536870952 = 0 --Use default destination AR server > > Has anybody else experienced this? > > Thanks, > Jason > > ARS 7.5 p4 > Atrium Core 7.6 p1 > Win 2008 R2 64-bit > SQL 2008 64-bit > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
