BMC Remedy Email Engine can not start
I always get this alert message when I try to start the BMC Remedy Email Engine Service: The BMC Remedy Email Engine - remtest1 on Local Computer started and then stopped. Some services stop automatically if they have no work to do, for example, the Performance Logs and Alerts service. After this message is displayed, the service is still stopped. Here are the properties for this service: Startup Tpe: Automatic Start parameters: Log on as: Local System account Hardware Profile: Profile 1 - Enabled This service depends on the following system components: Remedy Action Request System Server I tried restarting the Remedy Action Request System Server, no avail. I tried rebooting the whole server, still no avail. Any thoughts? Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] -- Some people see things as they are and say... Why? I dream of things that never were and say... Why not? ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: BMC Remedy Email Engine can not start
Hi Bruce, How do I go about changing the service login to the account that has access to the email box used by the email app? I don't quite get that, can you please explain further, I'm still new at this. I wasn't the one who setup the Email Engine, the person who did it is on vacation. What do you mean by email box? What do you mean by service login? Thanks!! Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] -- Some people see things as they are and say... Why? I dream of things that never were and say... Why not? _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Scott Sent: Monday, February 26, 2007 12:01 PM To: arslist@ARSLIST.ORG Subject: Re: BMC Remedy Email Engine can not start ** I've seen this before at my last job. You need to change the service login to the account that has access to the email box used by the email application. In other words, if the email box on the exchange server is allocated to remtest1, the service login name should be remtest1 as well. Thanks, Bruce _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Mikhail Serate Sent: Monday, February 26, 2007 11:47 AM To: arslist@ARSLIST.ORG Subject: BMC Remedy Email Engine can not start ** I always get this alert message when I try to start the BMC Remedy Email Engine Service: The BMC Remedy Email Engine - remtest1 on Local Computer started and then stopped. Some services stop automatically if they have no work to do, for example, the Performance Logs and Alerts service. After this message is displayed, the service is still stopped. Here are the properties for this service: Startup Tpe: Automatic Start parameters: Log on as: Local System account Hardware Profile: Profile 1 - Enabled This service depends on the following system components: Remedy Action Request System Server I tried restarting the Remedy Action Request System Server, no avail. I tried rebooting the whole server, still no avail. Any thoughts? Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] -- Some people see things as they are and say... Why? I dream of things that never were and say... Why not? __20060125___This posting was submitted with HTML in it___ _ The information contained in this electronic mail message, including attachments, if any, is PetSmart confidential information. It is intended only for the use of the person(s) named above. If the reader of this message is not the intended recipient, or has received this message in error, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you are not the intended recipient or have received this message in error, please notify the sender via e-mail and promptly delete the original message. _ __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: BMC Remedy Email Engine can not start
PROTECTED], smtps=javax.mail.Provider[TRANSPORT,smtps,com.sun.mail.smtp.SMTPSSLTransport ,Sun Microsystems, Inc], mapitransport=javax.mail.Provider[TRANSPORT,mapitransport,com.remedy.mail.ma pi.MAPITransport,[EMAIL PROTECTED], pop3=javax.mail.Provider[STORE,pop3,com.sun.mail.pop3.POP3Store,Sun Microsy stems, Inc], pop3s=javax.mail.Provider[STORE,pop3s,com.sun.mail.pop3.POP3SSLStore,Sun Microsystems, Inc], smtp=javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun Microsystems, Inc]} DEBUG: successfully loaded resource: /META-INF/javamail.default.address.map DEBUG: URL jar:file:/C:/Program%20Files/AR%20System/AREmail/smtp.jar!/META-INF/javamail .address.map DEBUG: successfully loaded resource: jar:file:/C:/Program%20Files/AR%20System/AREmail/smtp.jar!/META-INF/javamail .address.map DEBUG: java.io.FileNotFoundException: C:\Program Files\Java\jre1.5.0_10\lib\javamail.address.map (The system cannot find the file specified) A0 OK CAPABILITY A1 LOGIN remedy remedy1 A1 OK You are so in A2 LIST INBOX * LIST (\Noinferiors) / INBOX A2 OK Completed (0.000 secs 2 calls) DEBUG: connection available -- size: 1 A3 SELECT INBOX * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)] * 0 EXISTS * 0 RECENT * OK [UIDVALIDITY 1152524667] * OK [UIDNEXT 515] A3 OK [READ-WRITE] Completed A4 CLOSE A4 OK Completed DEBUG: added an Authenticated connection -- size: 1 A5 NOOP A5 OK Completed A6 LOGOUT * BYE LOGOUT received A6 OK Completed Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] -- Some people see things as they are and say... Why? I dream of things that never were and say... Why not? _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of L. J. Head Sent: Monday, February 26, 2007 1:13 PM To: arslist@ARSLIST.ORG Subject: Re: BMC Remedy Email Engine can not start ** I had this problem last week while I was upgrading my Java...I updated all of my paths and all but still couldn't get it to start. I eventually copied my new patch version into the old directory to get it to start properly...still haven't figured out where the reference to the old dir was _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Mikhail Serate Sent: Monday, February 26, 2007 11:47 AM To: arslist@ARSLIST.ORG Subject: BMC Remedy Email Engine can not start ** I always get this alert message when I try to start the BMC Remedy Email Engine Service: The BMC Remedy Email Engine - remtest1 on Local Computer started and then stopped. Some services stop automatically if they have no work to do, for example, the Performance Logs and Alerts service. After this message is displayed, the service is still stopped. Here are the properties for this service: Startup Tpe: Automatic Start parameters: Log on as: Local System account Hardware Profile: Profile 1 - Enabled This service depends on the following system components: Remedy Action Request System Server I tried restarting the Remedy Action Request System Server, no avail. I tried rebooting the whole server, still no avail. Any thoughts? Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] -- Some people see things as they are and say... Why? I dream of things that never were and say... Why not? __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: SSO Problem: AREA being called more than once
Suresh, For mine, it was giving it the right username: mrserate the first time (SSO says okay). But a few milliseconds later it calls it again (this time SSO says no!). Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] -- Some people see things as they are and say... Why? I dream of things that never were and say... Why not? _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Shanmugadas, Suresh Sent: Wednesday, February 14, 2007 5:15 PM To: arslist@ARSLIST.ORG Subject: Re: SSO Problem: AREA being called more than once ** I had this issue and the reason for my AREA plugin getting called twice was because, the userid that was sent from Midtier was slightly different from what I would get without SSSO. ex. Normally, I would get it as username : suresh.shanmugadas but with the SSSO I was sending it as [EMAIL PROTECTED] and since I had AREA chaining and because SSSO was not able to Authenticate the user as [EMAIL PROTECTED] it was firing the LDAP authentication. That was the reason it was firing twice for me. HTH Suresh _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Axton Sent: Wednesday, January 31, 2007 3:13 PM To: arslist@ARSLIST.ORG Subject: Re: SSO Problem: AREA being called more than once ** Add the bits together to implement multiple parameters. e.g., a value of 31 will disable all callbacks. Axton Grams On 1/31/07, Ben Chernys [EMAIL PROTECTED] wrote: ** First, I would code the AREA plug-in to handle all calls properly. You do not need to authenticate on the subsequent calls unless a timeout is reached. You will need to provide address info and an OK return code. Then, yes, 16 seems like it should work though the comments are confusing. Perhaps 7 is more correct. Note that you will have to restart the plug-in server to reload this value. Try it and see Ben _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Mikhail Serate Sent: January 30, 2007 10:33 PM To: arslist@ARSLIST.ORG Subject: Re: SSO Problem: AREA being called more than once ** Hello Ben, I looked at the Configuration Guide's list of the parameters related to area and notification and this is what i found: Option: External-Authentication-Return-Data-Capabilities Description: A bit mask that allows you to specify the return data capabilities for the current AREA plugin. This setting does not control the AREA plugin, it merely desecribes the behavior of the plugin, allowing for server optimization. Acceptable values are as follows: - Bit 1 (Value = 1) - no email address will be provided - Bit 2 (Value = 2) - no notify mechanism will be provided - Bit 3 (Value = 4) - no group identifiers will be provided - Bit 4 (Value = 8) - no license information will be provided. - Bit 5 (Value = 16) - no notification user validation should occur. The default is 0, meaning the server wil attempt to retrieve this information from AREA. A value of 7 will allow the server to potentially reduce the number of AREA related calls during notification processing. A value of 16 will allow the server to avoid using AREA for notification user validation and information retrieval. Use this setting for sites using a form of AREA that applies user names as email addresses and where there is no benefit to accessing an authentication database. So if I put the External-Authentication-Return-Data-Capabilities in the ar.cfg and set it to 16, will ARS stop calling AREA twice? Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] -- Some people see things as they are and say... Why? I dream of things that never were and say... Why not? _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Shanmugadas, Suresh Sent: Monday, January 29, 2007 2:28 PM To: arslist@ARSLIST.ORG Subject: Re: SSO Problem: AREA being called more than once ** Hi Mikhail/Fellow Listers I am facing the exact same problem like yours today. but I am implementing AREA SSSO for the firsttime in 7.0.1. I am passing 2 secret passwords from Midtier. So when the Callback function in AREA is called , it validates these values and it is successful. but it gets called again for some reason and this time it is getting my windows login credentials in the parameters sent to AREA and it is failing. Our Env: ARS 7.0.1 Midtier 7.0.1 Win 2003 server IIS/TOMCAT IE PLGN TID: 000472 RPC ID: 01 Queue: AREA Client-RPC: 390695 AREA.SURESH.CUSTOM.SSO INFO Username: PLGN TID: 000472 RPC ID: 01 Queue: AREA Client-RPC: 390695
Re: LoginServlet goto paramter gets cut off
Hello Michelle Thanks for the reply. We have been using the LoginServlet before with Midtier version 6.3 and it was working perfectly. The reason why we are using LoginServlet instead of the ViewFormServlet was that the ViewFormServlet wouldn't work with the Portal we are using (we are calling these links from the portal with an SSO token). The LoginServlet URL format that worked for us before was this: https:// https://midtier/arsys/servlet/LoginServlet?username=userpwd=SSO_token goto=/arsys/forms/server/form_name/Online/?mode=Submit midtier/arsys/servlet/LoginServlet?username=userpwd=SSO_tokengoto=/a rsys/forms/server/form_name/Online/?mode=Submit We used exactly the same format after upgrading to Midtier 7 and now it won't work. It will simply cut off the =Submit therefore by default, it sets the mode to Search. Ideas? Thanks! Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] -- Some people see things as they are and say... Why? I dream of things that never were and say... Why not? _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Lucero, Michelle - IST contractor Sent: Friday, February 02, 2007 8:20 AM To: arslist@ARSLIST.ORG Subject: Re: LoginServlet goto paramter gets cut off ** Hi, Mikhail: Try using the ViewFormServlet instead. It automatically logs the user in and opens the form in submit mode. http://midtier/arsys/servlet/ViewFormServlet?server=myserver http://midtier/arsys/servlet/ViewFormServlet?server=myserverform=myformvi ew=myviewmode=Submitusername=userpwd=password form=myformview=myviewmode=Submitusername=userpwd=password Tested successfully on Mid-Tier 7.0.0 P1 and Mid-Tier 7.0.01 P1. By the way, no matter what variation of the LoginServlet I tried, it opened in Search mode every time. Through all the versions of the Mid-Tier, I always seem to have the most success using ViewFormServlet. Thanks, Michelle _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Mikhail Serate Sent: Thursday, February 01, 2007 5:19 PM To: arslist@ARSLIST.ORG Subject: LoginServlet goto paramter gets cut off ** Hello List We're having problems with the goto parameter in our LoginServlet. We're passing in the correct parameter values, however after passing it in, it cuts of parts of the goto parameter: The URL we want to go to: https://midtier/arsys/forms/remprod1/PS_Access_New/Online/?mode=Submit https://midtier/arsys/forms/remprod1/PS_Access_New/Online/?mode=Submit The URL we pass pass in: https://midtier/arsys/servlet/LoginServlet?username=USERpwd=PASSWORDgoto= /arsys/forms/remprod1/PS_Access_New/Online/?mode=Submit https://midtier/arsys/servlet/LoginServlet?username=USERpwd=PASSWORDgoto=/ arsys/forms/remprod1/PS_Access_New/Online/?mode=Submit The URL displayed after browser processes the URL being passed in: https://midtier/arsys/forms/remprod1/PS_Access_New/Online/?modecacheid=b92 d20a9 https://midtier/arsys/forms/remprod1/PS_Access_New/Online/?modecacheid=b92d 20a9 As you can see, the =Submit is being cut off! What's going on? Our environment: Midtier Version 7.0.00 Patch 2 Please advise. Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] -- Some people see things as they are and say... Why? I dream of things that never were and say... Why not? __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
LoginServlet goto paramter gets cut off
Hello List We're having problems with the goto parameter in our LoginServlet. We're passing in the correct parameter values, however after passing it in, it cuts of parts of the goto parameter: The URL we want to go to: https://midtier/arsys/forms/remprod1/PS_Access_New/Online/?mode=Submit The URL we pass pass in: https://midtier/arsys/servlet/LoginServlet?username=USERpwd=PASSWORDgoto=/ arsys/forms/remprod1/PS_Access_New/Online/?mode=Submit The URL displayed after browser processes the URL being passed in: https://midtier/arsys/forms/remprod1/PS_Access_New/Online/?modecacheid=b92d 20a9 As you can see, the =Submit is being cut off! What's going on? Our environment: Midtier Version 7.0.00 Patch 2 Please advise. Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] -- Some people see things as they are and say... Why? I dream of things that never were and say... Why not? ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: SSO Problem: AREA being called more than once
Hello, So we tried a value of 16, that didn't work. We tried 7, and that didn't work either. The AREA is still being called twice. Here are some logs (user.log) to show it attempts to login twice (I'm going to cut off the first few columns to make it not clutter as much): USER: mrserate /* Wed Jan 31 2007 15:23:12.5030 */ INFO EXT AUTH Use Remedy Info (username in user.txt); return buff=2,Return code = 0, Password authentication successful USER: mrserate /* Wed Jan 31 2007 15:23:12.5030 */ LOGIN mrserate USER: mrserate /* Wed Jan 31 2007 15:23:12.5030 */ FIXED RELEASEmrserate USER: mrserate /* Wed Jan 31 2007 15:23:12.5030 */ LOGOUT mrserate USER: mrserate /* Wed Jan 31 2007 15:23:12.5500 */ INFO EXT AUTH Use Remedy Info (username in user.txt); return buff=2,Return code = 0, Password authentication successful USER: mrserate /* Wed Jan 31 2007 15:23:12.5500 */ LOGIN mrserate USER: mrserate /* Wed Jan 31 2007 15:23:12.5500 */ FIXED RELEASEmrserate USER: mrserate /* Wed Jan 31 2007 15:23:12.5500 */ LOGOUT mrserate As you can see clearly, it calls AREA twice within a few milliseconds from each other. So if I was using a Single Sign-On, this obviously wouldn't work because a single-use token cannot be used twice. Would anyone have an idea as to why it is still calling the AREA twice? Thanks for all your help :) Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] -- Some people see things as they are and say... Why? I dream of things that never were and say... Why not? _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Ben Chernys Sent: Wednesday, January 31, 2007 5:05 AM To: arslist@ARSLIST.ORG Subject: Re: SSO Problem: AREA being called more than once ** First, I would code the AREA plug-in to handle all calls properly. You do not need to authenticate on the subsequent calls unless a timeout is reached. You will need to provide address info and an OK return code. Then, yes, 16 seems like it should work though the comments are confusing. Perhaps 7 is more correct. Note that you will have to restart the plug-in server to reload this value. Try it and see Ben _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Mikhail Serate Sent: January 30, 2007 10:33 PM To: arslist@ARSLIST.ORG Subject: Re: SSO Problem: AREA being called more than once ** Hello Ben, I looked at the Configuration Guide's list of the parameters related to area and notification and this is what i found: Option: External-Authentication-Return-Data-Capabilities Description: A bit mask that allows you to specify the return data capabilities for the current AREA plugin. This setting does not control the AREA plugin, it merely desecribes the behavior of the plugin, allowing for server optimization. Acceptable values are as follows: - Bit 1 (Value = 1) - no email address will be provided - Bit 2 (Value = 2) - no notify mechanism will be provided - Bit 3 (Value = 4) - no group identifiers will be provided - Bit 4 (Value = 8) - no license information will be provided. - Bit 5 (Value = 16) - no notification user validation should occur. The default is 0, meaning the server wil attempt to retrieve this information from AREA. A value of 7 will allow the server to potentially reduce the number of AREA related calls during notification processing. A value of 16 will allow the server to avoid using AREA for notification user validation and information retrieval. Use this setting for sites using a form of AREA that applies user names as email addresses and where there is no benefit to accessing an authentication database. So if I put the External-Authentication-Return-Data-Capabilities in the ar.cfg and set it to 16, will ARS stop calling AREA twice? Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] -- Some people see things as they are and say... Why? I dream of things that never were and say... Why not? _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Shanmugadas, Suresh Sent: Monday, January 29, 2007 2:28 PM To: arslist@ARSLIST.ORG Subject: Re: SSO Problem: AREA being called more than once ** Hi Mikhail/Fellow Listers I am facing the exact same problem like yours today. but I am implementing AREA SSSO for the firsttime in 7.0.1. I am passing 2 secret passwords from Midtier. So when the Callback function in AREA is called , it validates these values and it is successful. but it gets called again for some reason and this time
Re: SSO Problem: AREA being called more than once
Hello Ben, I looked at the Configuration Guide's list of the parameters related to area and notification and this is what i found: Option: External-Authentication-Return-Data-Capabilities Description: A bit mask that allows you to specify the return data capabilities for the current AREA plugin. This setting does not control the AREA plugin, it merely desecribes the behavior of the plugin, allowing for server optimization. Acceptable values are as follows: - Bit 1 (Value = 1) - no email address will be provided - Bit 2 (Value = 2) - no notify mechanism will be provided - Bit 3 (Value = 4) - no group identifiers will be provided - Bit 4 (Value = 8) - no license information will be provided. - Bit 5 (Value = 16) - no notification user validation should occur. The default is 0, meaning the server wil attempt to retrieve this information from AREA. A value of 7 will allow the server to potentially reduce the number of AREA related calls during notification processing. A value of 16 will allow the server to avoid using AREA for notification user validation and information retrieval. Use this setting for sites using a form of AREA that applies user names as email addresses and where there is no benefit to accessing an authentication database. So if I put the External-Authentication-Return-Data-Capabilities in the ar.cfg and set it to 16, will ARS stop calling AREA twice? Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] -- Some people see things as they are and say... Why? I dream of things that never were and say... Why not? _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Shanmugadas, Suresh Sent: Monday, January 29, 2007 2:28 PM To: arslist@ARSLIST.ORG Subject: Re: SSO Problem: AREA being called more than once ** Hi Mikhail/Fellow Listers I am facing the exact same problem like yours today. but I am implementing AREA SSSO for the firsttime in 7.0.1. I am passing 2 secret passwords from Midtier. So when the Callback function in AREA is called , it validates these values and it is successful. but it gets called again for some reason and this time it is getting my windows login credentials in the parameters sent to AREA and it is failing. Our Env: ARS 7.0.1 Midtier 7.0.1 Win 2003 server IIS/TOMCAT IE PLGN TID: 000472 RPC ID: 01 Queue: AREA Client-RPC: 390695 AREA.SURESH.CUSTOM.SSO INFO Username: PLGN TID: 000472 RPC ID: 01 Queue: AREA Client-RPC: 390695 AREA.SURESH.CUSTOM.SSO INFO [EMAIL PROTECTED] PLGN TID: 000472 RPC ID: 01 Queue: AREA Client-RPC: 390695 AREA.SURESH.CUSTOM.SSO INFO Password: PLGN TID: 000472 RPC ID: 01 Queue: AREA Client-RPC: 390695 AREA.SURESH.CUSTOM.SSO INFO FIRSTPASS PLGN TID: 000472 RPC ID: 01 Queue: AREA Client-RPC: 390695 AREA.SURESH.CUSTOM.SSO INFO Network Address: PLGN TID: 000472 RPC ID: 01 Queue: AREA Client-RPC: 390695 AREA.SURESH.CUSTOM.SSO INFO 10.XXX.XX.XXX PLGN TID: 000472 RPC ID: 01 Queue: AREA Client-RPC: 390695 AREA.SURESH.CUSTOM.SSO INFO Auth String: PLGN TID: 000472 RPC ID: 01 Queue: AREA Client-RPC: 390695 AREA.SURESH.CUSTOM.SSO INFO SECONDPASS PLGN TID: 000472 RPC ID: 01 Queue: AREA Client-RPC: 390695 AREA.SURESH.CUSTOM.SSO INFO From AREA PASS_STRING: PLGN TID: 000472 RPC ID: 01 Queue: AREA Client-RPC: 390695 AREA.SURESH.CUSTOM.SSO INFO FIRSTPASS PLGN TID: 000472 RPC ID: 01 Queue: AREA Client-RPC: 390695 AREA.SURESH.CUSTOM.SSO INFO From AREA AUTH_STRING_DEFAULT: PLGN TID: 000472 RPC ID: 01 Queue: AREA Client-RPC: 390695 AREA.SURESH.CUSTOM.SSO INFO SECONDPASS PLGN TID: 000472 RPC ID: 01 Queue: AREA Client-RPC: 390695 AREA.SURESH.CUSTOM.SSO INFO User logging in from a matching Authentication String and Mid-Tier IP: PLGN TID: 000472 RPC ID: 01 Queue: AREA Client-RPC: 390695 AREA.SURESH.CUSTOM.SSO INFO 10.XXX.XX.XXX PLGN TID: 000472 RPC ID: 01 Queue: AREA Client-RPC: 390695 AREA.SURESH.CUSTOM.SSO INFO User passed AREA SSO authentication. Login Success PLGN TID: 000472 RPC ID: 01 Queue: AREA Client-RPC: 390695 -VL OK PLGN TID: 000472 RPC ID: 03 Queue: AREA Client-RPC: 390695 +NSAREANeedToSyncCallback PLGN TID: 000472 RPC ID: 03 Queue: AREA Client-RPC: 390695 -NS OK -- 0 PLGN TID: 000472 RPC ID: 05 Queue: AREA Client-RPC: 390695 +VLAREAVerifyLoginCallback -- user suresh.shanmugadas PLGN TID: 000472 RPC ID: 05 Queue: AREA Client-RPC: 390695 AREA.SURESH.CUSTOM.SSO INFO Username: PLGN TID: 000472 RPC ID: 05 Queue: AREA Client-RPC: 390695
SSO Problem: AREA being called more than once
Hi List, Has anyone ever had any problems with their AREA being called more than once? In the password field, a one-time-use token is being passed in. AREA then calls SSO with that token, then SSO verifies the validity of the token. However since the AREA code is being called more than once, the same token that was being validated the first time it went through, is being validated again, and so SSO of course will say no. The AREA code we are using now is exactly the same as our old AREA code in ARS 6.3, which worked (we upgraded to ARS 7.0). Does anyone have any thoughts on this? Please let me know. Thanks! Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] -- Some people see things as they are and say... Why? I dream of things that never were and say... Why not? ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Web Apps on MidTier. How is it rendered?
Hello List, I would really like to know how the web applications on MidTier is being rendered? Is it using Javascript? Reason I'm asking is that I'm trying to do some load/performance testing on the applications on midtier using open source testing tools. However I think the web apps on midtier is a special case. Any other regular form can be perfomance-tested very easily. If anyone can point me to any resource out there, or better yet, an open source testing tool that is compatible with remedy, please let me know.. Thanks, Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] -- Some people see things as they are and say... Why? I dream of things that never were and say... Why not? ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Load Testing on Midtier
Hello List, Our team would like to do some load testing on our apps on the web. I tried to contact rocKnot a few days ago and got a reply that their Load Challenger application isn't available any longer. I tried WAPT but I can't even get the virtual users to login, so they can't even enter data in the fields. We are looking for a user-friendly application that allows us to create about 20 virtual users all running at the same time, entering data into the fields and finally submitting a ticket. The reason being is that we want to see how well (or bad) our midtier server is after switching from AIX to Windows. Thanks for all your help. Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] -- Some people see things as they are and say... Why? I dream of things that never were and say... Why not? ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Java Search Record API
Hi Tom, Thanks for your reply.
If I try the same piece of code on a different server (remprod using ARS
6.3), it works perfectly fine. It just breaks down in remtest (ARS 7.0).
Mikhail Serate
Remedy Development Team
Information Technologies
University of Calgary
(403) 210-9308
[EMAIL PROTECTED]
If debugging is the process of removing bugs, then programming must be the
process of putting them in.
_
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Tim Widowfield
Sent: Wednesday, December 20, 2006 11:25 PM
To: arslist@ARSLIST.ORG
Subject: Re: Java Search Record API
**
Mikhail,
I'm sorry I didn't notice your message earlier.
I have crashed the JVM from time to time when I have accidentally passed a
null object as part of a method argument. The people who wrote the Java API
weren't the most careful programmers, so in some cases where you'd expect a
NullPointerException to be thrown, you instead get a crashed JVM. The null
gets passed all the way to the JNI layer where mayhem ensues.
I've found that I have to be very careful to test every object before I use
it. A simple try/catch block won't cut it. Sadly, the only way I've found
to be safe is to literally check for null with an if statement, and then
proceed only when I know it's OK.
I'm not saying that's your problem, but it's a species of bug that's bitten
me more than once.
Tim Widowfield
http://www.widowfield.com
- Original Message
From: Mikhail Serate [EMAIL PROTECTED]
To: arslist@ARSLIST.ORG
Sent: Friday, December 8, 2006 11:55:07 AM
Subject: [ARSLIST] Java Search Record API
**
Hello List,
I've got an API that searches for a Record X in Form A. I created a Java API
for this under the 6.3 version on our test server and it worked fine. Now
we've upgraded this server to 7.0.00 Patch 002 200607211559 and when I ran
it, it gives me this error:
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# Internal Error (455843455054494F4E530E43505000FB), pid=7952, tid=2692
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_12-b03 mixed mode)
# An error report file with more information is saved as hs_err_pid7952.log
#
# If you would like to submit a bug report, please visit:
#http://java.sun.com/webapps/bugreport/crash.jsp
http://java.sun.com/webapps/bugreport/crash.jsp
#
This is the line where it crashes:
Field[] formFields = FieldFactory.findObjects(userInfo, fListCrit, fCrit);
This is the snippet of code that goes before the above:
if(debugMode) System.out.println(retrieving... );
try {
// Set the field criteria to retrieve all field info
if(debugMode) System.out.println(\tSetting field criteria to
retrieve all field info...);
FieldCriteria fCrit = new FieldCriteria();
fCrit.setRetrieveAll(true);
// Retrieve all types of fields
if(debugMode) System.out.println(\tRetrieve all types of fields);
FieldListCriteria fListCrit = new FieldListCriteria(formName, new
Timestamp(0), FieldType.AR_ALL_FIELD);
// Load the field array with all fields in the form
if(debugMode) System.out.println(\tLoad the field array with all
fields in the form);
Field[] formFields = FieldFactory.findObjects(userInfo, fListCrit,
fCrit);
.
.
}
This is our server information (test):
--
Mid Tier Version - 7.0.00 Patch 002 200607211559
Web Server Information - Microsoft IIS ServletExec/5.0.0.10
Operating System Name - Windows 2003
Java Version - 1.5.0_10
--
I tested the same API on our production server and it works just fine. This
is the server info:
--
Mid Tier Version - 6.03.00 patch 015
Web Server Information - IBM WebSphere Application Server/5.1
Operating System Name - AIX
Java Version - 1.4.2
--
All I know is that for Java APIs, when upgrading to a different version, as
long as I'm using the same libraries as I used in a previous version, it
should work just as fine. So I'm thinking it could be a problem with the
server?
If anyone can give me any information about this problem that would be
greatly appreciated.
Thanks!
Mikhail Serate
Remedy Development Team
Information Technologies
University of Calgary
[EMAIL PROTECTED]
__20060125___This posting was submitted with HTML in
it___
__20060125___This posting was submitted with HTML in
it___
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the
Answers Are
MidTier Service problems
Hello List, Everytime a user logs in externally to Remedy, they'd always get the ARERR [623] Authentication failed. In the aruser.log, it says that our EXT AUTH authenticates the user successfully, logs him in, then releases him, and finally logs him out. Then right after that it's all LOGIN FAILED MidTier Service (password). Yesterday, everything worked perfectly. But when I started tinkering around with our test server (to solve other problems), this problem with the midtier service started! These are the things that I did in the test server (sequentially): --- Uninstalled the current version of java. Installed a different (lower) version of java. [ Restarted the server ] Replaced arapi70.dll and arapi70.jar with arapi51.dll and arapi70.jar [ Restarted the server ] Replaced arapi51.dll and arapi51.jar with arapi63.dll and arapi63.jar [ Restarted the server ] ( Someone reported the midtier is not working. So I tried restoring it back to the original settings ) Replaced arapi63.dll and arapi63.jar with arapi70.dll and arapi70.jar [ Restarted the server ] Uninstalled the current version of java. Reinstalled the version of java we were using. [ Restarted the server ] --- Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] If debugging is the process of removing bugs, then programming must be the process of putting them in. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Java Search Record API
Hello List,
I've got an API that searches for a Record X in Form A. I created a Java API
for this under the 6.3 version on our test server and it worked fine. Now
we've upgraded this server to 7.0.00 Patch 002 200607211559 and when I ran
it, it gives me this error:
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# Internal Error (455843455054494F4E530E43505000FB), pid=7952, tid=2692
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_12-b03 mixed mode)
# An error report file with more information is saved as hs_err_pid7952.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
This is the line where it crashes:
Field[] formFields = FieldFactory.findObjects(userInfo, fListCrit, fCrit);
This is the snippet of code that goes before the above:
if(debugMode) System.out.println(retrieving... );
try {
// Set the field criteria to retrieve all field info
if(debugMode) System.out.println(\tSetting field criteria to
retrieve all field info...);
FieldCriteria fCrit = new FieldCriteria();
fCrit.setRetrieveAll(true);
// Retrieve all types of fields
if(debugMode) System.out.println(\tRetrieve all types of fields);
FieldListCriteria fListCrit = new FieldListCriteria(formName, new
Timestamp(0), FieldType.AR_ALL_FIELD);
// Load the field array with all fields in the form
if(debugMode) System.out.println(\tLoad the field array with all
fields in the form);
Field[] formFields = FieldFactory.findObjects(userInfo, fListCrit,
fCrit);
.
.
}
This is our server information (test):
--
Mid Tier Version - 7.0.00 Patch 002 200607211559
Web Server Information - Microsoft IIS ServletExec/5.0.0.10
Operating System Name - Windows 2003
Java Version - 1.5.0_10
--
I tested the same API on our production server and it works just fine. This
is the server info:
--
Mid Tier Version - 6.03.00 patch 015
Web Server Information - IBM WebSphere Application Server/5.1
Operating System Name - AIX
Java Version - 1.4.2
--
All I know is that for Java APIs, when upgrading to a different version, as
long as I'm using the same libraries as I used in a previous version, it
should work just as fine. So I'm thinking it could be a problem with the
server?
If anyone can give me any information about this problem that would be
greatly appreciated.
Thanks!
Mikhail Serate
Remedy Development Team
Information Technologies
University of Calgary
[EMAIL PROTECTED]
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the
Answers Are
Re: C API -- Create Ticket using Email: Category, Type, Item not working
Title: C API --> Create Ticket using Email: Category, Type, Item not working ** Hello Craig, Thanks for your reply. That made me think, because the values for "Item" relies on what is being selected in "Type", which also relies on what's being selected in "Category". But yet, these are valid values for all fields. If I choose "To be categorized" in "Category", then I can choose "To be categorized" in "Type" and so then also "To be categorized" for "Item". But when I view the ticket in User Tool, the values for Category, Type, and Item are still blank. Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Carter, Craig J Civ ARPC/DPDSent: Wednesday, October 04, 2006 6:06 AMTo: arslist@ARSLIST.ORGSubject: Re: C API -- Create Ticket using Email: Category, Type, Item not working ** You didnt mention the application but are these valid values for those fields? In CSS, the value is generally Uncategorized for the default value. CRAIG J. CARTER From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mikhail SerateSent: Tuesday, October 03, 2006 5:05 PMTo: arslist@ARSLIST.ORGSubject: C API -- Create Ticket using Email: Category, Type, Item not working Hello List, I can successfully create a ticket using our Email API in C. But for some reason, when we view the ticket in Remedy User tool, the Category, Type, and Item fields are left blank. These fields are required fields, so it is interesting why these are blank when viewed in Remedy User tool. In the API, we assigned these fields as: Category (20003) : "To be categorized" Type (20004) : "To be categorized" Item (20005) : "To be categorized" Has anyone come across this kind of problem before? Anyone have any ideas what's going on? Thank you, Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
Re: C API -- Create Ticket using Email: Category, Type, Item not working
Title: C API --> Create Ticket using Email: Category, Type, Item not working ** Hello all, The problem has been solved. i didn't know that an innocent looking Active Link was clearing up the CTIvalues everytime someone opens the ticket through theuser tool. Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Carter, Craig J Civ ARPC/DPDSent: Wednesday, October 04, 2006 8:55 AMTo: arslist@ARSLIST.ORGSubject: Re: C API -- Create Ticket using Email: Category, Type, Item not working ** What do you see when you look at the fields in the database? Are they populated with the correct values? Since those are valid values, have you checked for workflow that is clearing those values on display when they are To be categorized? Some alternate tests: If you create a ticket via your API with other valid CTI values, do they show up okay? If so, your API calls are probably fine. 2. If you create the same ticket manually via the WUT and use To be categorized for the CTI values, does To be categorized show up when you reopen the ticket? Not knowing what application you are referring to, Im just throwing out ideas //SIGNED// CRAIG J. CARTER From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mikhail SerateSent: Wednesday, October 04, 2006 8:23 AMTo: arslist@ARSLIST.ORGSubject: Re: C API -- Create Ticket using Email: Category, Type, Item not working Hello Craig, Thanks for your reply. That made me think, because the values for "Item" relies on what is being selected in "Type", which also relies on what's being selected in "Category". But yet, these are valid values for all fields. If I choose "To be categorized" in "Category", then I can choose "To be categorized" in "Type" and so then also "To be categorized" for "Item". But when I view the ticket in User Tool, the values for Category, Type, and Item are still blank. Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Carter, Craig J Civ ARPC/DPDSent: Wednesday, October 04, 2006 6:06 AMTo: arslist@ARSLIST.ORGSubject: Re: C API -- Create Ticket using Email: Category, Type, Item not working ** You didnt mention the application but are these valid values for those fields? In CSS, the value is generally Uncategorized for the default value. CRAIG J. CARTER From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mikhail SerateSent: Tuesday, October 03, 2006 5:05 PMTo: arslist@ARSLIST.ORGSubject: C API -- Create Ticket using Email: Category, Type, Item not working Hello List, I can successfully create a ticket using our Email API in C. But for some reason, when we view the ticket in Remedy User tool, the Category, Type, and Item fields are left blank. These fields are required fields, so it is interesting why these are blank when viewed in Remedy User tool. In the API, we assigned these fields as: Category (20003) : "To be categorized" Type (20004) : "To be categorized" Item (20005) : "To be categorized" Has anyone come across this kind of problem before? Anyone have any ideas what's going on? Thank you, Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it_20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
Re: C API -- Create Ticket using Email: Category, Type, Item not working
Title: C API --> Create Ticket using Email: Category, Type, Item not working ** I forgot to say thank you for all the help! :) Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Carter, Craig J Civ ARPC/DPDSent: Wednesday, October 04, 2006 8:55 AMTo: arslist@ARSLIST.ORGSubject: Re: C API -- Create Ticket using Email: Category, Type, Item not working ** What do you see when you look at the fields in the database? Are they populated with the correct values? Since those are valid values, have you checked for workflow that is clearing those values on display when they are To be categorized? Some alternate tests: If you create a ticket via your API with other valid CTI values, do they show up okay? If so, your API calls are probably fine. 2. If you create the same ticket manually via the WUT and use To be categorized for the CTI values, does To be categorized show up when you reopen the ticket? Not knowing what application you are referring to, Im just throwing out ideas //SIGNED// CRAIG J. CARTER From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mikhail SerateSent: Wednesday, October 04, 2006 8:23 AMTo: arslist@ARSLIST.ORGSubject: Re: C API -- Create Ticket using Email: Category, Type, Item not working Hello Craig, Thanks for your reply. That made me think, because the values for "Item" relies on what is being selected in "Type", which also relies on what's being selected in "Category". But yet, these are valid values for all fields. If I choose "To be categorized" in "Category", then I can choose "To be categorized" in "Type" and so then also "To be categorized" for "Item". But when I view the ticket in User Tool, the values for Category, Type, and Item are still blank. Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Carter, Craig J Civ ARPC/DPDSent: Wednesday, October 04, 2006 6:06 AMTo: arslist@ARSLIST.ORGSubject: Re: C API -- Create Ticket using Email: Category, Type, Item not working ** You didnt mention the application but are these valid values for those fields? In CSS, the value is generally Uncategorized for the default value. CRAIG J. CARTER From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mikhail SerateSent: Tuesday, October 03, 2006 5:05 PMTo: arslist@ARSLIST.ORGSubject: C API -- Create Ticket using Email: Category, Type, Item not working Hello List, I can successfully create a ticket using our Email API in C. But for some reason, when we view the ticket in Remedy User tool, the Category, Type, and Item fields are left blank. These fields are required fields, so it is interesting why these are blank when viewed in Remedy User tool. In the API, we assigned these fields as: Category (20003) : "To be categorized" Type (20004) : "To be categorized" Item (20005) : "To be categorized" Has anyone come across this kind of problem before? Anyone have any ideas what's going on? Thank you, Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it_20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
C API -- Create Ticket using Email: Category, Type, Item not working
Title: C API -- Create Ticket using Email: Category, Type, Item not working ** Hello List, I can successfully create a ticket using our Email API in C. But for some reason, when we view the ticket in Remedy User tool, the Category, Type, and Item fields are left blank. These fields are required fields, so it is interesting why these are blank when viewed in Remedy User tool. In the API, we assigned these fields as: Category (20003) : To be categorized Type (20004) : To be categorized Item (20005) : To be categorized Has anyone come across this kind of problem before? Anyone have any ideas what's going on? Thank you, Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] __20060125___This posting was submitted with HTML in it___
Intances of Remedy Plugins Not Terminated in Server
Title: Intances of Remedy Plugins Not Terminated in Server ** Hello List, We are getting instances of Remedy plugins being initialized but left hanging in our server. Since the server was restarted yesterday, we had about 300 plugin instances still floating around left unterminated. I'm just wondering if anyone else out there had this problem before and what they did to remedy it. We are currently using Mid Tier 6.3, Patch 15, IBM WebSphere Application Server 5.1, AIX 5.1. Thanks! Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] __20060125___This posting was submitted with HTML in it___
Re: Intances of Remedy Plugins Not Terminated in Server
Hello Carey, Sorry I worded it wrong. We don't exactly know how many times the plugin was being loaded (or if it is being loaded at all), but we do know that there are many unclosed connections to Remedy after the request is finished. Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
