Re: Confusion over AR_SERVER_INFO values as changed in the Rel 9 API - even worse with 9.1.0

[Misi Mladoniczky]

Hi Mark,

Do you really think that the server will map 379 to 380 depending on the
client API version? The API version in ar.h seems to be the same in the sample
Ben gave us.

To me it seems unsettling that the C-API is not updated in the same way as the
Java-API. But I guess this was bound to happen. If there is no longer a
C-API-Admin-Tool but instead a Java-API-DevStudio, there is no point in
keeping the C-API up to date.

In any event I will be increasingly afraid to do Admin-changes through the
C-API...

Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)

Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.

> Ben,
>
> I'm not 100% certain but my understanding is that the API version does not
> indicate the server version but the version of the API specification - the
> values below are from the ar.h file?  If so this is the API/RPC revision level
> that a client built using that API will conform to.  The server will have a
> corresponding max API revision number and the two will negotiate to the
> highest supported by both.  If you want the server version you'll have to make
> a GSI call for operation number 4.
>
> If you check the API logs from a 9.1 server you should see some clients with
> protocol version 23 so it looks like the C and Java APIs may be at different
> levels in 9.1.
>
> I've tried to put together a list of release and protocol/db versions here -
> https://communities.bmc.com/docs/DOC-37267
>
> Mark
>
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG] On Behalf Of Ben Chernys
> Sent: 17 March 2016 02:17
> To: arslist@ARSLIST.ORG
> Subject: Re: Confusion over AR_SERVER_INFO values as changed in the Rel 9 API
> - even worse with 9.1.0
>
> **
> Well folks,
>
> I'm afraid it just got a lot worse!!!
>
> 9.1.0 identifies itself as 9.0.0 but has a different set of AR_SERVER_INFO
> values:
>
>>From 9.0.0
> #define AR_CURRENT_API_VERSION   21  /* current api version */
> #define AR_MAX_SERVER_INFO_USED 426  /* set "highest" server info */
>
>>From 9.1.0
> #define AR_CURRENT_API_VERSION   21  /* current api version */
> #define AR_MAX_SERVER_INFO_USED 443  /* set "highest" server info */
>
> I suppose it is too late for BMC to fix this absolute mess.   How is one's
> source code to differentiate between 9.0.0 and 9.1.0 - given that they both
> identify themselves as the same release and given that they have different
> symbols defined?  I suppose it means that AR_CURRENT_API_VERSION is NOT to be
> used to identify the API release but rather AR_MAX_SERVER_INFO_USED (as long
> as you don't go back far enough that that symbol is not defined) or possibly a
> combination of the two symbols.
>
> I have yet to look at the actual INFO values themselves and shudder to think
> what I may find.
>
> Cheers
> Ben
>
> From: Ben Chernys [mailto:ben.cher...@softwaretoolhouse.com]
> Sent: March-01-16 10:24
> To: 'arslist@ARSLIST.ORG'
> Subject: Confusion over AR_SERVER_INFO values as changed in the Rel 9 API
>
> Hi Folks,
>
> I am just trying to get my head around the AR_SERVER_INFO changes introduced
> in release 9.
>
> ARS 9 does something not done previously with these values:
> It changes the integer in some Info values and deletes some Info values
>
> Image this scenario:  You have a release 9 API accessing a Release 8 server.
> Which symbol do you use for a release 8 value?  There are no symbols for
> deleted values which are still legitimate on the 8 server.  The symbol defined
> in the 9 API will request the wrong value on an 8 server.
>
> Similarly, you have a release 8 API accessing a release 9 server:  When you
> ask for an Info that has had a number change, what do you get?
>
> For now, I will have to get around the problem by not asking for contentious
> info values.  Heaven forbid that someone wants these values :)
>
> I question how something this basic and simple could have been turned into
> something this obtuse and convoluted.  I also question what the API itself
> does when "maintaining compatibility" across server releases.
>
> Kudos to BMC, they have maintained excellent compatibility across server
> releases when it comes to the data portion of the API.
> This is the first release which does not.  Any comments from BMC would be
> welcome.
>
> Details:
>
> Release 8.1 API
>
> -  These are all dropped in 9:
> #define AR_SERVER_INFO_MESSAGE_BROKER_URL 374 /* char - Message Broker
> URL */
> #define AR_SERVER_INFO_NUMBER_OF_SELECTOR_THREADS 375 /* int - Number of
> selector threads. */
> #define AR_SERVER_INFO_MESSAGE_BROKER_PORT376 /* int - Messsaging(JMS)
> broker port. */
> #define AR_SERVER_INFO_JMX_PORT   377 /* int - JMX Port */
> #define

Turn off AREA LDAP Polling?

[Sinclair, Keith]

If I recall correctly, there is a way to tell Remedy to not make periodic AD 
checks every so often with a user's account that signed into Remedy using AREA 
LDAP but for the life of me, I cannot remember how or where it's done.

Anyone know where the setting is at?

Keith Sinclair
Remedy Development
ShopperTrak Chicago, USA
O 312.676.8289
ksincl...@shoppertrak.com | shoppertrak.com
Retail Profitability, Improved.


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Group IDs --> Group Names

[Andrew Fremont]

Yeah,

That is what I'm looking for , Didn't know there is a such process command.
Thank Jim.

On Fri, Mar 18, 2016 at 11:38 AM, Jim Bruce  wrote:

> If you have both values (before and after change), maybe you could use
> PERFORM-ACTION-MAP-GROUPIDS-TO-NAMES process.
>
> If field GroupListBefore contains: 1;2;5;
> And field GroupListAfter contains: 1;2;
>
> A couple Set Field actions:
>
> - GroupListAsText = $PROCESS$ PERFORM-ACTION-MAP-GROUPIDS-TO-NAMES
> $GroupListBefore$
> (will return "Administrator Customize Sub Administrator")
>
> - GroupListAsText = $PROCESS$ PERFORM-ACTION-MAP-GROUPIDS-TO-NAMES
> $GroupListAfter$
> (will return "Administrator Customize")
>
> Hope this is what you are looking for.
> -Jim
>
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> "Where the Answers Are, and have been for 20 years"
>

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Confusion over AR_SERVER_INFO values as changed in the Rel 9 API - even worse with 9.1.0

[Ben Chernys]

Hi Misi,

Not true re keeping the c API up-to-date.  BMC still delivers many binaries 
with the c API (in both 32 and 64 bits) in the 9.1.0 installation.  And the 
point is beyond BMC anyhow.  They publish it and it should work.  It should 
also allow a higher API to communicate with lower servers.

Cheers
Ben

-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky
Sent: March-17-16 05:57
To: arslist@ARSLIST.ORG
Subject: Re: Confusion over AR_SERVER_INFO values as changed in the Rel 9 API - 
even worse with 9.1.0

Hi Mark,

Do you really think that the server will map 379 to 380 depending on the client 
API version? The API version in ar.h seems to be the same in the sample Ben 
gave us.

To me it seems unsettling that the C-API is not updated in the same way as the 
Java-API. But I guess this was bound to happen. If there is no longer a 
C-API-Admin-Tool but instead a Java-API-DevStudio, there is no point in keeping 
the C-API up to date.

In any event I will be increasingly afraid to do Admin-changes through the 
C-API...

Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)

Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.

> Ben,
>
> I'm not 100% certain but my understanding is that the API version does 
> not indicate the server version but the version of the API 
> specification - the values below are from the ar.h file?  If so this 
> is the API/RPC revision level that a client built using that API will 
> conform to.  The server will have a corresponding max API revision 
> number and the two will negotiate to the highest supported by both.  
> If you want the server version you'll have to make a GSI call for operation 
> number 4.
>
> If you check the API logs from a 9.1 server you should see some 
> clients with protocol version 23 so it looks like the C and Java APIs 
> may be at different levels in 9.1.
>
> I've tried to put together a list of release and protocol/db versions 
> here -
> https://communities.bmc.com/docs/DOC-37267
>
> Mark
>
> From: Action Request System discussion list(ARSList) 
> [mailto:arslist@ARSLIST.ORG] On Behalf Of Ben Chernys
> Sent: 17 March 2016 02:17
> To: arslist@ARSLIST.ORG
> Subject: Re: Confusion over AR_SERVER_INFO values as changed in the 
> Rel 9 API
> - even worse with 9.1.0
>
> **
> Well folks,
>
> I'm afraid it just got a lot worse!!!
>
> 9.1.0 identifies itself as 9.0.0 but has a different set of 
> AR_SERVER_INFO
> values:
>
>>From 9.0.0
> #define AR_CURRENT_API_VERSION   21  /* current api version */
> #define AR_MAX_SERVER_INFO_USED 426  /* set "highest" server info */
>
>>From 9.1.0
> #define AR_CURRENT_API_VERSION   21  /* current api version */
> #define AR_MAX_SERVER_INFO_USED 443  /* set "highest" server info */
>
> I suppose it is too late for BMC to fix this absolute mess.   How is one's
> source code to differentiate between 9.0.0 and 9.1.0 - given that they 
> both identify themselves as the same release and given that they have 
> different symbols defined?  I suppose it means that 
> AR_CURRENT_API_VERSION is NOT to be used to identify the API release 
> but rather AR_MAX_SERVER_INFO_USED (as long as you don't go back far 
> enough that that symbol is not defined) or possibly a combination of the two 
> symbols.
>
> I have yet to look at the actual INFO values themselves and shudder to 
> think what I may find.
>
> Cheers
> Ben
>
> From: Ben Chernys [mailto:ben.cher...@softwaretoolhouse.com]
> Sent: March-01-16 10:24
> To: 'arslist@ARSLIST.ORG'
> Subject: Confusion over AR_SERVER_INFO values as changed in the Rel 9 
> API
>
> Hi Folks,
>
> I am just trying to get my head around the AR_SERVER_INFO changes 
> introduced in release 9.
>
> ARS 9 does something not done previously with these values:
> It changes the integer in some Info values and deletes some Info 
> values
>
> Image this scenario:  You have a release 9 API accessing a Release 8 server.
> Which symbol do you use for a release 8 value?  There are no symbols 
> for deleted values which are still legitimate on the 8 server.  The 
> symbol defined in the 9 API will request the wrong value on an 8 server.
>
> Similarly, you have a release 8 API accessing a release 9 server:  
> When you ask for an Info that has had a number change, what do you get?
>
> For now, I will have to get around the problem by not asking for 
> contentious info values.  Heaven forbid that someone wants these 
> values :)
>
> I question how something this basic and simple could have been turned 
> into something this obtuse and convoluted.  I also question what the 
> API itself does when "maintaining compatibility" across server releases.
>
> Kudos to 

Re: Confusion over AR_SERVER_INFO values as changed in the Rel 9 API - even worse with 9.1.0

[Misi Mladoniczky]

Hi,

The numbering sees very important to me.

In 7.6 and 8.0 AR_SERVER_INFO_API_MONITORING_UPDATE_INTERVAL did not exist,
but here are the numbers in the other versions.

api764sp5/ar.h:#define AR_CURRENT_API_VERSION 18
api800/ar.h:   #define AR_CURRENT_API_VERSION 19
api812sp1/ar.h:#define AR_CURRENT_API_VERSION 20
api812sp1/ar.h:#define AR_SERVER_INFO_API_MONITORING_UPDATE_INTERVAL 380
api900/ar.h:   #define AR_CURRENT_API_VERSION 21
api900/ar.h:   #define AR_SERVER_INFO_API_MONITORING_UPDATE_INTERVAL 379
api901/ar.h:   #define AR_CURRENT_API_VERSION 21
api901/ar.h:   #define AR_SERVER_INFO_API_MONITORING_UPDATE_INTERVAL 379
api910/ar.h:   #define AR_CURRENT_API_VERSION 21
api910/ar.h:   #define AR_SERVER_INFO_API_MONITORING_UPDATE_INTERVAL 379

Best Regards - Misi, RRR AB, http://rrr.se

> Misi,
>
> I don't know about the original issue that Ben pointed out - the renumbering
> of some values.  What I tried to say is that the AR_CURRENT_API_VERSION
> defined in the ar.h tells you the API version that a client built using that
> set of API files will use - it shouldn't be used to determine the version of
> the server that they shipped with.  If you look at the 8.1 releases all three
> versions (RTM, SP1 and SP2) have API version 21 but 9.0 is 21 and 9.0 SP1 is
> 22 - at least for the Java API.  It looks as though the C API has stayed at
> the same level between 9.x releases.
>
> I'll have a look at the SERVER_INFO values and see if I can find out why they
> were changed between 8 and 9 - was there a reason or a mistake.
>
> Mark
>
> -Original Message-
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky
> Sent: 17 March 2016 11:57
> To: arslist@ARSLIST.ORG
> Subject: Re: Confusion over AR_SERVER_INFO values as changed in the Rel 9 API
> - even worse with 9.1.0
>
> Hi Mark,
>
> Do you really think that the server will map 379 to 380 depending on the
> client API version? The API version in ar.h seems to be the same in the sample
> Ben gave us.
>
> To me it seems unsettling that the C-API is not updated in the same way as the
> Java-API. But I guess this was bound to happen. If there is no longer a
> C-API-Admin-Tool but instead a Java-API-DevStudio, there is no point in
> keeping the C-API up to date.
>
> In any event I will be increasingly afraid to do Admin-changes through the
> C-API...
>
> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
>
> Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
> Find these products, and many free tools and utilities, at http://rrr.se.
>
>> Ben,
>>
>> I'm not 100% certain but my understanding is that the API version does
>> not indicate the server version but the version of the API
>> specification - the values below are from the ar.h file?  If so this
>> is the API/RPC revision level that a client built using that API will
>> conform to.  The server will have a corresponding max API revision
>> number and the two will negotiate to the highest supported by both.
>> If you want the server version you'll have to make a GSI call for operation
>> number 4.
>>
>> If you check the API logs from a 9.1 server you should see some
>> clients with protocol version 23 so it looks like the C and Java APIs
>> may be at different levels in 9.1.
>>
>> I've tried to put together a list of release and protocol/db versions
>> here -
>> https://communities.bmc.com/docs/DOC-37267
>>
>> Mark
>>
>> From: Action Request System discussion list(ARSList)
>> [mailto:arslist@ARSLIST.ORG] On Behalf Of Ben Chernys
>> Sent: 17 March 2016 02:17
>> To: arslist@ARSLIST.ORG
>> Subject: Re: Confusion over AR_SERVER_INFO values as changed in the
>> Rel 9 API
>> - even worse with 9.1.0
>>
>> **
>> Well folks,
>>
>> I'm afraid it just got a lot worse!!!
>>
>> 9.1.0 identifies itself as 9.0.0 but has a different set of
>> AR_SERVER_INFO
>> values:
>>
>>>From 9.0.0
>> #define AR_CURRENT_API_VERSION   21  /* current api version */
>> #define AR_MAX_SERVER_INFO_USED 426  /* set "highest" server info */
>>
>>>From 9.1.0
>> #define AR_CURRENT_API_VERSION   21  /* current api version */
>> #define AR_MAX_SERVER_INFO_USED 443  /* set "highest" server info */
>>
>> I suppose it is too late for BMC to fix this absolute mess.   How is one's
>> source code to differentiate between 9.0.0 and 9.1.0 - given that they
>> both identify themselves as the same release and given that they have
>> different symbols defined?  I suppose it means that
>> AR_CURRENT_API_VERSION is NOT to be used to identify the API release
>> but rather AR_MAX_SERVER_INFO_USED (as long as you don't go back far
>> enough that that symbol is not defined) or possibly a combination of the two
>> symbols.
>>
>> I have yet to look at the actual INFO values themselves and 

Re: Hanging escalations?

[remedyboy]

Same version of Java ?
Just wondering 


Sent from my iPhone

> On Mar 16, 2016, at 2:18 PM, Misi Mladoniczky  wrote:
> 
> Hi,
> 
> It would be interesting to know more about what the escalation is actually
> doing. Number of records, what is the action, etc.
> 
> I have a handy tool to compare config files that you can download here:
> https://rrr.se/cgi/tools/main?tool=rrrConfDiff
> 
>Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
> 
> Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
> Find these products, and many free tools and utilities, at http://rrr.se.
> 
>> All,
>> 
>> Have an interesting one; we have an ARS 7.5/ITSM 7.6 system running on :
>> 1 server RHL, used for integration/CMDB processing
>> 2 servers running Solaris, in an active/passive load balanced environment,
>> users will typically use either of these.
>> 
>> Users normally connect to the server designated as primary (ie. the active).
>> 
>> We implemented some new functionality driven from escalations - runs
>> absolutely fine on our test environments, but it has started to fail on the
>> active server.  And when I say "fail", I mean that all escalations just
>> grind to a halt the moment when this new functionality is invoked.  Nothing
>> explanatory in arerror.log, I have full filter/escalation logging enabled
>> (on a per thread basis), and it gives no error either - escalations just
>> plain stop.
>> 
>> What makes this interesting is that if I run this same process (same change
>> request, same data, etc) via the integration server or the secondary, it
>> runs without any problems.
>> 
>> As far as I can tell we have the escalations threads setup the same on both
>> of the "user" solaris servers
>> Server #1 (which fails)
>> Private-RPC-Socket:  390601   1   1
>> Private-RPC-Socket:  390603   3   8  (escalations threads)
>> Private-RPC-Socket:  390620  12  30
>> Private-RPC-Socket:  390630   3   4
>> Private-RPC-Socket:  390635  12  30
>> Private-RPC-Socket:  390680  15  30
>> 
>> Server #2 (which runs fine)
>> Private-RPC-Socket:  390601   1   1
>> Private-RPC-Socket:  390603   3   8
>> Private-RPC-Socket:  390620  12  30
>> Private-RPC-Socket:  390635  12  30
>> Private-RPC-Socket:  390680  15  30
>> 
>> I am thinking of going through the various configurations in ar.conf and
>> aligning the failing primary wherever possible/practical - but any hints as
>> to why it could be failing welcome!
>> 
>> Regards
>> 
>> Dave Barber
>> 
>> ___
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> "Where the Answers Are, and have been for 20 years"
> 
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> "Where the Answers Are, and have been for 20 years"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Hanging escalations?

[Dave Barber]

Hi Rod,

Filter logging against the relevant thread just shows processing stopping.
No errors, it just hangs.

I am considering a change in server configuration - moving the escalations
processing from the "user" primary to the integration server.  Users (aside
from me and the other developers) never log onto there, it would in theory
free up some server load on the user facing servers.

Regards

Dave

On 16 March 2016 at 22:14, Rod Harris  wrote:

> **
> Hi Dave,
>
> From what you describe it does sound like your escalation is stuck in some
> kind of infinite loop. You should put filter logging on the server that is
> hosting your escalation. You may find that your filters being triggered by
> the escalation are never completing and perhaps timing out prior to the end
> of the transaction. This may cause the transaction to roll back and for the
> same condition to trigger again and again, not giving anything else a look
> in. When this happens you may see very little in the escalation log for the
> impacted pool.
>
> The root cause of this may be a difference in data or configuration
> between servers or may also be that the workflow is not designed to scale
> to production loaded servers.
>
> Hope this helps,
>
> Rod Harris
>
>
>
> On 17 March 2016 at 08:49, Dave Barber  wrote:
>
>> **
>> Just realised a flaw in my earlier checks - all 3 servers are in a server
>> group, escalations can only run on one server in the group.
>>
>> So regardless of which server triggers the escalation process into action
>> (setting a value on a form), the escalation will always run on the same
>> server - and subsequently the related filters will also only run on the
>> server nominated for escalations ...
>>
>> And doing these checks after having been up for about 18 hours isn't
>> advisable 
>>
>> Regards
>>
>> Dave
>>
>> On 16 March 2016 at 20:26, Dave Barber  wrote:
>>
>>> All 3 servers are running from the same database (ie. same codebase).
>>>
>>> The two solaris servers are (supposedly) identical hardware and builds
>>> (Solaris, Java, etc.).  The Red Hat box is totally different in almost
>>> every possible way (processors, memory, probably java version).  And it is
>>> only on one of the two Solaris boxes where the escalation fails.
>>>
>>> The escalation in question triggers a table loop through a list of
>>> impacted areas related to a change, in order to build a contact list for
>>> notifications.  The data set in question has around 6,500 impacted areas to
>>> loop through, remove duplicate customers/contacts, etc.  The actual set of
>>> filters triggered are best described as "complicated".  But as it runs fine
>>> on two of the three servers, that is why I am considering AR Server
>>> configuration issues - and it is easier for me to investigate and change
>>> such things.
>>>
>>> I'll check out your confdiff app Misi, much appreciated (currently using
>>> Notepad++ with a comparison plugin).
>>>
>>> Regards
>>>
>>> Dave
>>>
>>> On 16 March 2016 at 19:26,  wrote:
>>>
 Same version of Java ?
 Just wondering


 Sent from my iPhone

 > On Mar 16, 2016, at 2:18 PM, Misi Mladoniczky  wrote:
 >
 > Hi,
 >
 > It would be interesting to know more about what the escalation is
 actually
 > doing. Number of records, what is the action, etc.
 >
 > I have a handy tool to compare config files that you can download
 here:
 > https://rrr.se/cgi/tools/main?tool=rrrConfDiff
 >
 >Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP
 2011)
 >
 > Ask the Remedy Licensing Experts (Best R.O.I. Award at
 WWRUG10/11/12/13):
 > * RRR|License - Not enough Remedy licenses? Save money by optimizing.
 > * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy
 logs.
 > Find these products, and many free tools and utilities, at
 http://rrr.se.
 >
 >> All,
 >>
 >> Have an interesting one; we have an ARS 7.5/ITSM 7.6 system running
 on :
 >> 1 server RHL, used for integration/CMDB processing
 >> 2 servers running Solaris, in an active/passive load balanced
 environment,
 >> users will typically use either of these.
 >>
 >> Users normally connect to the server designated as primary (ie. the
 active).
 >>
 >> We implemented some new functionality driven from escalations - runs
 >> absolutely fine on our test environments, but it has started to fail
 on the
 >> active server.  And when I say "fail", I mean that all escalations
 just
 >> grind to a halt the moment when this new functionality is invoked.
 Nothing
 >> explanatory in arerror.log, I have full filter/escalation logging
 enabled
 >> (on a per thread basis), and it gives no error either - escalations
 just
 >> plain stop.
 >>
 >> What makes this interesting is that if I run this same process (same
 change
 >> request, same data, etc

Re: BMC Remedy Skype Intergration

[Grooms, Frederick W]

Do you have Skype/Lync application?   Try opening a browser and put in the URL 
the SIP:emailaddress (No Slashes, that was a typo in my earlier response)

Sip (being a protocol like FTP) have MIME associations for them, so the 
standard browser will associate the SIP to call the Lync (or Skype) application 
and use the app as normal.

Fred

-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Jamie
Sent: Thursday, March 17, 2016 10:55 AM
To: arslist@ARSLIST.ORG
Subject: Re: BMC Remedy Skype Intergration

Hello Fred,

I was interested in your comment where you said you can launch a chat window 
with Skype/Lync using SIP://emailaddress.  However, when I reached out to my 
exchange team that supports our Skype/Lync platform, they weren't aware of this 
capability and aren't sure how it can be done.  Can you provide a little more 
information on this?

Thanks!
Jamie




___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Having issue while navigating to the Report console for the Knowledge Usage report

[Abhishek Anand]

Hi Expert,

 

While navigating in report console  to Knowledge -> Open Knowledge -> Article 
Usagewe are getting below error:-

 

Multiple exceptions occurred. Caused by: ERROR (361): An unqualified search was 
issued and the server has been configured to disallow unqualified searches.

We are using OOB report only and its  ITSM 8.1.02

 

Please suggest on it and early response will be highly appreciated.

 

Cheers,

AA

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Confusion over AR_SERVER_INFO values as changed in the Rel 9 API - even worse with 9.1.0

[Walters, Mark]

Misi,

I don't know about the original issue that Ben pointed out - the renumbering of 
some values.  What I tried to say is that the AR_CURRENT_API_VERSION defined in 
the ar.h tells you the API version that a client built using that set of API 
files will use - it shouldn't be used to determine the version of the server 
that they shipped with.  If you look at the 8.1 releases all three versions 
(RTM, SP1 and SP2) have API version 21 but 9.0 is 21 and 9.0 SP1 is 22 - at 
least for the Java API.  It looks as though the C API has stayed at the same 
level between 9.x releases.

I'll have a look at the SERVER_INFO values and see if I can find out why they 
were changed between 8 and 9 - was there a reason or a mistake.

Mark

-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky
Sent: 17 March 2016 11:57
To: arslist@ARSLIST.ORG
Subject: Re: Confusion over AR_SERVER_INFO values as changed in the Rel 9 API - 
even worse with 9.1.0

Hi Mark,

Do you really think that the server will map 379 to 380 depending on the client 
API version? The API version in ar.h seems to be the same in the sample Ben 
gave us.

To me it seems unsettling that the C-API is not updated in the same way as the 
Java-API. But I guess this was bound to happen. If there is no longer a 
C-API-Admin-Tool but instead a Java-API-DevStudio, there is no point in keeping 
the C-API up to date.

In any event I will be increasingly afraid to do Admin-changes through the 
C-API...

Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)

Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.

> Ben,
>
> I'm not 100% certain but my understanding is that the API version does
> not indicate the server version but the version of the API
> specification - the values below are from the ar.h file?  If so this
> is the API/RPC revision level that a client built using that API will
> conform to.  The server will have a corresponding max API revision
> number and the two will negotiate to the highest supported by both.
> If you want the server version you'll have to make a GSI call for operation 
> number 4.
>
> If you check the API logs from a 9.1 server you should see some
> clients with protocol version 23 so it looks like the C and Java APIs
> may be at different levels in 9.1.
>
> I've tried to put together a list of release and protocol/db versions
> here -
> https://communities.bmc.com/docs/DOC-37267
>
> Mark
>
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG] On Behalf Of Ben Chernys
> Sent: 17 March 2016 02:17
> To: arslist@ARSLIST.ORG
> Subject: Re: Confusion over AR_SERVER_INFO values as changed in the
> Rel 9 API
> - even worse with 9.1.0
>
> **
> Well folks,
>
> I'm afraid it just got a lot worse!!!
>
> 9.1.0 identifies itself as 9.0.0 but has a different set of
> AR_SERVER_INFO
> values:
>
>>From 9.0.0
> #define AR_CURRENT_API_VERSION   21  /* current api version */
> #define AR_MAX_SERVER_INFO_USED 426  /* set "highest" server info */
>
>>From 9.1.0
> #define AR_CURRENT_API_VERSION   21  /* current api version */
> #define AR_MAX_SERVER_INFO_USED 443  /* set "highest" server info */
>
> I suppose it is too late for BMC to fix this absolute mess.   How is one's
> source code to differentiate between 9.0.0 and 9.1.0 - given that they
> both identify themselves as the same release and given that they have
> different symbols defined?  I suppose it means that
> AR_CURRENT_API_VERSION is NOT to be used to identify the API release
> but rather AR_MAX_SERVER_INFO_USED (as long as you don't go back far
> enough that that symbol is not defined) or possibly a combination of the two 
> symbols.
>
> I have yet to look at the actual INFO values themselves and shudder to
> think what I may find.
>
> Cheers
> Ben
>
> From: Ben Chernys [mailto:ben.cher...@softwaretoolhouse.com]
> Sent: March-01-16 10:24
> To: 'arslist@ARSLIST.ORG'
> Subject: Confusion over AR_SERVER_INFO values as changed in the Rel 9
> API
>
> Hi Folks,
>
> I am just trying to get my head around the AR_SERVER_INFO changes
> introduced in release 9.
>
> ARS 9 does something not done previously with these values:
> It changes the integer in some Info values and deletes some Info
> values
>
> Image this scenario:  You have a release 9 API accessing a Release 8 server.
> Which symbol do you use for a release 8 value?  There are no symbols
> for deleted values which are still legitimate on the 8 server.  The
> symbol defined in the 9 API will request the wrong value on an 8 server.
>
> Similarly, you have a release 8 API accessing a release 9 server:
> When you ask for an Info that has had a number change, wha

Re: Confusion over AR_SERVER_INFO values as changed in the Rel 9 API - even worse with 9.1.0

[Misi Mladoniczky]

Hi,

It seems to me that it would be better to change/patch 9.1 if the problems
started there. There is a lot of legacy from all previous versions that it
might be harder to fix than just having BMC change their most recent code.

Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)

Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.

> Well folks,
>
>
>
> I'm afraid it just got a lot worse!!!
>
>
>
> 9.1.0 identifies itself as 9.0.0 but has a different set of AR_SERVER_INFO
> values:
>
>
>
>>From 9.0.0
>
> #define AR_CURRENT_API_VERSION   21  /* current api version */
>
> #define AR_MAX_SERVER_INFO_USED 426  /* set "highest" server info */
>
>
>
>>From 9.1.0
>
> #define AR_CURRENT_API_VERSION   21  /* current api version */
>
> #define AR_MAX_SERVER_INFO_USED 443  /* set "highest" server info */
>
>
>
> I suppose it is too late for BMC to fix this absolute mess.   How is one's
> source code to differentiate between 9.0.0 and 9.1.0 - given that they both
> identify themselves as the same release and given that they have different
> symbols defined?  I suppose it means that AR_CURRENT_API_VERSION is NOT to
> be used to identify the API release but rather AR_MAX_SERVER_INFO_USED (as
> long as you don't go back far enough that that symbol is not defined) or
> possibly a combination of the two symbols.
>
>
>
> I have yet to look at the actual INFO values themselves and shudder to think
> what I may find.
>
>
>
> Cheers
>
> Ben
>
>
>
> From: Ben Chernys [mailto:ben.cher...@softwaretoolhouse.com]
> Sent: March-01-16 10:24
> To: 'arslist@ARSLIST.ORG'
> Subject: Confusion over AR_SERVER_INFO values as changed in the Rel 9 API
>
>
>
> Hi Folks,
>
>
>
> I am just trying to get my head around the AR_SERVER_INFO changes introduced
> in release 9.
>
>
>
> ARS 9 does something not done previously with these values:
>
> It changes the integer in some Info values and deletes some Info values
>
>
>
> Image this scenario:  You have a release 9 API accessing a Release 8 server.
>
> Which symbol do you use for a release 8 value?  There are no symbols for
> deleted values which are still legitimate on the 8 server.  The symbol
> defined in the 9 API will request the wrong value on an 8 server.
>
>
>
> Similarly, you have a release 8 API accessing a release 9 server:  When you
> ask for an Info that has had a number change, what do you get?
>
>
>
> For now, I will have to get around the problem by not asking for contentious
> info values.  Heaven forbid that someone wants these values J
>
>
>
> I question how something this basic and simple could have been turned into
> something this obtuse and convoluted.  I also question what the API itself
> does when "maintaining compatibility" across server releases.
>
>
>
> Kudos to BMC, they have maintained excellent compatibility across server
> releases when it comes to the data portion of the API.
>
> This is the first release which does not.  Any comments from BMC would be
> welcome.
>
>
>
> Details:
>
>
>
> Release 8.1 API
>
> -  These are all dropped in 9:
>
> #define AR_SERVER_INFO_MESSAGE_BROKER_URL 374 /* char - Message
> Broker URL */
>
> #define AR_SERVER_INFO_NUMBER_OF_SELECTOR_THREADS 375 /* int - Number of
> selector threads. */
>
> #define AR_SERVER_INFO_MESSAGE_BROKER_PORT376 /* int -
> Messsaging(JMS) broker port. */
>
> #define AR_SERVER_INFO_JMX_PORT   377 /* int - JMX Port */
>
> #define AR_SERVER_INFO_PEER_LISTENER_PORT 378 /* int - (Cache)
> Peer-listener-port */
>
> -  These are renumbered in 9:
>
> #define AR_SERVER_INFO_API_MONITORING_UPDATE_INTERVAL 379 /* int - Update
> Interval for API Monitoring */
>
> #define AR_SERVER_INFO_API_RECORDING_CLIENT_TYPE  380 /* char - API
> Recording on for specific Client Type */
>
> #define AR_SERVER_INFO_API_RECORDING_ENABLE   381 /* int - Enable Flag
> would be set to T or F */
>
> #define AR_SERVER_INFO_API_RECORDING_CLIENT_TYPE  380 /* char - API
> Recording on for specific Client Type */
>
> #define AR_SERVER_INFO_API_RECORDING_ENABLE   381 /* int - Enable Flag
> would be set to T or F */
>
> #define AR_SERVER_INFO_OBJ_RESERVATION_REPOSITORY_TYPE 382 /* int - Object
> reservation repository type - 0  ARS; 10 External */
>
> -  This value has a different meaning in 9:
>
> #define AR_SERVER_INFO_SERVICE_RECORDING_ENABLE   383 /* int - flag to
> enable the Service Monitoring */
>
> -  Now they align with 9
>
> #define AR_SERVER_INFO_STATS_APISQL_CONTROL   384 /* Bitmask for controlling
> API/SQL display to console, exception logging option, etc. */
>
>
>
> Release 9 APIRelease 9 has no 379 J
>
> #define AR_SERVER_INFO_API_MONITORING_UPDATE_INTERVAL380  /* int -

Re: Turn off AREA LDAP Polling?

[Danny Kellett]

I think its AR system Administration Console > General > Server info >
EA Tab > Need to Sync. Set this to 0
 
-- 
Danny Kellett
dkell...@javasystemsolutions.com
 
 
 
On Wed, Mar 16, 2016, at 01:57 PM, Sinclair, Keith wrote:
> **







>
> If I recall correctly, there is a way to tell Remedy to not make
> periodic AD checks every so often with a user’s account that signed
> into Remedy using AREA LDAP but for the life of me, I cannot remember
> how or where it’s done.
>
> Anyone know where the setting is at?
>
> *Keith Sinclair*
> Remedy Development
> ShopperTrak Chicago, USA
> *O* 312.676.8289
> ksincl...@shoppertrak.com | shoppertrak.com
> *Retail Profitability, Improved.*
>
> _ARSlist: "Where the Answers Are" and have been for 20 years_
>
 

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Turn off AREA LDAP Polling?

[Grooms, Frederick W]

And if you are looking for the AR.CONF (ar.CFG for Windows) value it is  
External-Authentication-Sync-Timeout


From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Sinclair, Keith
Sent: Wednesday, March 16, 2016 9:05 AM
To: arslist@ARSLIST.ORG
Subject: Re: Turn off AREA LDAP Polling?

**
Never mind. I found it.

For those of you who are wondering -

On the EA tab in the Server Information Configuration form, you'll see a box 
called "Need To Sync". If this is set to 0, Remedy won't periodically make AD 
checks.

From: Sinclair, Keith
Sent: Wednesday, March 16, 2016 8:58 AM
To: arslist@ARSLIST.ORG
Subject: Turn off AREA LDAP Polling?

If I recall correctly, there is a way to tell Remedy to not make periodic AD 
checks every so often with a user's account that signed into Remedy using AREA 
LDAP but for the life of me, I cannot remember how or where it's done.

Anyone know where the setting is at?

Keith Sinclair
Remedy Development
ShopperTrak Chicago, USA
O 312.676.8289
ksincl...@shoppertrak.com | shoppertrak.com
Retail Profitability, Improved.

_ARSlist: "Where the Answers Are" and have been for 20 years_

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Hanging escalations?

[Thomas Miskiewicz]

Dave,

it would be interesting to know what do those escalations do and what happens 
next.

For instance, do they push or set fields? 

How many records to they hit? (Turn on SQL Log and run that SQL manually to 
find out.)

What type of form Regular or Join do they work on? Which workflow gets 
triggered? What does it do? Again turn on the SQL Log and run those SQLs 
manually to see how many records get hit.


Thomas



> On 17 Mar 2016, at 08:11, Dave Barber  wrote:
> 
> **
> Hi Rod,
> 
> Filter logging against the relevant thread just shows processing stopping.  
> No errors, it just hangs.
> 
> I am considering a change in server configuration - moving the escalations 
> processing from the "user" primary to the integration server.  Users (aside 
> from me and the other developers) never log onto there, it would in theory 
> free up some server load on the user facing servers.
> 
> Regards
> 
> Dave
> 
> On 16 March 2016 at 22:14, Rod Harris  > wrote:
> **
> Hi Dave,
> 
> From what you describe it does sound like your escalation is stuck in some 
> kind of infinite loop. You should put filter logging on the server that is 
> hosting your escalation. You may find that your filters being triggered by 
> the escalation are never completing and perhaps timing out prior to the end 
> of the transaction. This may cause the transaction to roll back and for the 
> same condition to trigger again and again, not giving anything else a look 
> in. When this happens you may see very little in the escalation log for the 
> impacted pool.
> 
> The root cause of this may be a difference in data or configuration between 
> servers or may also be that the workflow is not designed to scale to 
> production loaded servers.
> 
> Hope this helps,
> 
> Rod Harris
> 
> 
> 
> On 17 March 2016 at 08:49, Dave Barber  > wrote:
> **
> Just realised a flaw in my earlier checks - all 3 servers are in a server 
> group, escalations can only run on one server in the group.
> 
> So regardless of which server triggers the escalation process into action 
> (setting a value on a form), the escalation will always run on the same 
> server - and subsequently the related filters will also only run on the 
> server nominated for escalations ...
> 
> And doing these checks after having been up for about 18 hours isn't 
> advisable 
> 
> Regards
> 
> Dave
> 
> On 16 March 2016 at 20:26, Dave Barber  > wrote:
> All 3 servers are running from the same database (ie. same codebase).
> 
> The two solaris servers are (supposedly) identical hardware and builds 
> (Solaris, Java, etc.).  The Red Hat box is totally different in almost every 
> possible way (processors, memory, probably java version).  And it is only on 
> one of the two Solaris boxes where the escalation fails.
> 
> The escalation in question triggers a table loop through a list of impacted 
> areas related to a change, in order to build a contact list for 
> notifications.  The data set in question has around 6,500 impacted areas to 
> loop through, remove duplicate customers/contacts, etc.  The actual set of 
> filters triggered are best described as "complicated".  But as it runs fine 
> on two of the three servers, that is why I am considering AR Server 
> configuration issues - and it is easier for me to investigate and change such 
> things.
> 
> I'll check out your confdiff app Misi, much appreciated (currently using 
> Notepad++ with a comparison plugin).
> 
> Regards
> 
> Dave
> 
> On 16 March 2016 at 19:26, mailto:remedy...@gmail.com>> 
> wrote:
> Same version of Java ?
> Just wondering
> 
> 
> Sent from my iPhone
> 
> > On Mar 16, 2016, at 2:18 PM, Misi Mladoniczky  > > wrote:
> >
> > Hi,
> >
> > It would be interesting to know more about what the escalation is actually
> > doing. Number of records, what is the action, etc.
> >
> > I have a handy tool to compare config files that you can download here:
> > https://rrr.se/cgi/tools/main?tool=rrrConfDiff 
> > 
> >
> >Best Regards - Misi, RRR AB, http://www.rrr.se  
> > (ARSList MVP 2011)
> >
> > Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
> > * RRR|License - Not enough Remedy licenses? Save money by optimizing.
> > * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
> > Find these products, and many free tools and utilities, at http://rrr.se 
> > .
> >
> >> All,
> >>
> >> Have an interesting one; we have an ARS 7.5/ITSM 7.6 system running on :
> >> 1 server RHL, used for integration/CMDB processing
> >> 2 servers running Solaris, in an active/passive load balanced environment,
> >> users will typically use either of these.
> >>
> >> Users normally connect to the server designated as primary (ie. the 
> >> active).
> >>
> >> We implemented some new functionality driven from 

Re: BMC Remedy Skype Intergration

[Jayesh]

Hi Brad,

If the service desk people are using outlook and skype then once the skype or 
lync conversation ends,it stores it in conversation history that can be  sent 
to itsm mailbox with whatever rule you have written in RBE:Rule to update the 
work info. I am not sure if we can write such automated rules in outlook.

-Original Message-
From: "Grooms, Frederick W" 
Sent: ‎16-‎03-‎2016 07:11 PM
To: "arslist@ARSLIST.ORG" 
Subject: Re: BMC Remedy Skype Intergration

** 
Starting a chat is simple…   Skype (was Lync) set itself up for the SIP 
protocol so all you have to do is to open a browser window to SIP://emailaddress
 
I don’t know about logging the chat session
 
Fred
 
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of BradRemedy
Sent: Wednesday, March 16, 2016 7:56 AM
To: arslist@ARSLIST.ORG
Subject: BMC Remedy Skype Intergration
 
** 
Hi
 
Has anyone integrated Skype with BMC Remedy at all? We are looking into options 
in which a chat conversation could be started for a call and the chat log is 
added as a work info to a ticket when the chat is finished.
 
I am busy investigating options however wanted to know if anyone else has done 
this sort of integration before.

Thanks in advance

Brad
 
 
_ARSlist: "Where the Answers Are" and have been for 20 years_ 
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Enterprise Password Recovery Management

[Brittain, Mark]

Hi All,

Has anyone done an integration with LieberSoft's Enterprise Password Recovery 
Management (EPRM) and ITSM 7.6.04? We're only doing a simple integration where 
EPRM queries an Incident Number to validate one exists. Set up the ITSM account 
and from the EPRM Console can authenticate with ITSM. However when we try to 
query an Incident, we get back the error "Could not verify ticket with Remedy - 
Failed to initialize the BMC remedy server!" on the EPRM console.

I am not seeing any issue in the logs so my thought is the request/query is not 
even getting there. We use a custom port and I suspect that is the issue. 
However no one knows how to configure this port in EPRM. Any insight, 
suggestions would be greatly appreciated.

Thanks
Mark

Mark Brittain
Sr. OSD Systems Engineer
ITILv3 Foundation, Continual Service Improvement
NaviSite, Inc. - A Time Warner Cable Company
mbritt...@navisite.com
Office: 315.634.9337
Mobile: 315.882.5360
[navsig]




This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: BMC Remedy Skype Intergration

[Grooms, Frederick W]

Starting a chat is simple…   Skype (was Lync) set itself up for the SIP 
protocol so all you have to do is to open a browser window to SIP://emailaddress

I don’t know about logging the chat session

Fred

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of BradRemedy
Sent: Wednesday, March 16, 2016 7:56 AM
To: arslist@ARSLIST.ORG
Subject: BMC Remedy Skype Intergration

**
Hi

Has anyone integrated Skype with BMC Remedy at all? We are looking into options 
in which a chat conversation could be started for a call and the chat log is 
added as a work info to a ticket when the chat is finished.

I am busy investigating options however wanted to know if anyone else has done 
this sort of integration before.

Thanks in advance

Brad



___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: BMC Remedy Skype Intergration

[David Charters]

Did you guys cover versions of Lync? There are some bugs depending on the 
version of Lync you are using.


Sent via the Samsung Galaxy S® 6 edge, an AT&T 4G LTE smartphone


 Original message 
From: "Grooms, Frederick W" 
Date: 3/17/2016 12:46 PM (GMT-05:00)
To: arslist@ARSLIST.ORG
Subject: Re: BMC Remedy Skype Intergration

Do you have Skype/Lync application?   Try opening a browser and put in the URL 
the SIP:emailaddress (No Slashes, that was a typo in my earlier response)

Sip (being a protocol like FTP) have MIME associations for them, so the 
standard browser will associate the SIP to call the Lync (or Skype) application 
and use the app as normal.

Fred

-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Jamie
Sent: Thursday, March 17, 2016 10:55 AM
To: arslist@ARSLIST.ORG
Subject: Re: BMC Remedy Skype Intergration

Hello Fred,

I was interested in your comment where you said you can launch a chat window 
with Skype/Lync using SIP://emailaddress.  However, when I reached out to my 
exchange team that supports our Skype/Lync platform, they weren't aware of this 
capability and aren't sure how it can be done.  Can you provide a little more 
information on this?

Thanks!
Jamie




___
UNSUBSCRIBE or access ARSlist Archives at 
www.arslist.org
"Where the Answers Are, and have been for 20 years"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Hanging escalations?

[Dave Barber]

Thomas,

The escalations poll for a value on a form, when found they trigger a
series of escalations that scan impacted areas against a change, look up
the customers/contacts and builds a list for then generating an email to
each individual customer with a list of the impacted areas.

As we had 3 servers in the server group, I decided that the integration
server should be designated for handling escalations.  Amended the server
group rankings, restarted the services on the integration server and the
primary user server (that had been handling the escalations).  And it now
works absolutely perfect - and considerably faster than it ever did before
(in this case Intel is better suited to the AR Server role than Sparc).

I would have loved to have found out why the process was failing on the
user facing server, but workflow logs (both filter and escalation) didn't
give any indication other than the last record that triggered the
escalation.

So a rearrangement of the server tasks resolved the issue.

Regards

Dave


On 17 March 2016 at 07:57, Thomas Miskiewicz  wrote:

> **
> Dave,
>
> it would be interesting to know what do those escalations do and what
> happens next.
>
> For instance, do they push or set fields?
>
> How many records to they hit? (Turn on SQL Log and run that SQL manually
> to find out.)
>
> What type of form Regular or Join do they work on? Which workflow gets
> triggered? What does it do? Again turn on the SQL Log and run those SQLs
> manually to see how many records get hit.
>
>
> Thomas
>
>
>
> On 17 Mar 2016, at 08:11, Dave Barber  > wrote:
>
> **
> Hi Rod,
>
> Filter logging against the relevant thread just shows processing
> stopping.  No errors, it just hangs.
>
> I am considering a change in server configuration - moving the escalations
> processing from the "user" primary to the integration server.  Users (aside
> from me and the other developers) never log onto there, it would in theory
> free up some server load on the user facing servers.
>
> Regards
>
> Dave
>
> On 16 March 2016 at 22:14, Rod Harris  wrote:
>
>> **
>> Hi Dave,
>>
>> From what you describe it does sound like your escalation is stuck in
>> some kind of infinite loop. You should put filter logging on the server
>> that is hosting your escalation. You may find that your filters being
>> triggered by the escalation are never completing and perhaps timing out
>> prior to the end of the transaction. This may cause the transaction to roll
>> back and for the same condition to trigger again and again, not giving
>> anything else a look in. When this happens you may see very little in the
>> escalation log for the impacted pool.
>>
>> The root cause of this may be a difference in data or configuration
>> between servers or may also be that the workflow is not designed to scale
>> to production loaded servers.
>>
>> Hope this helps,
>>
>> Rod Harris
>>
>>
>>
>> On 17 March 2016 at 08:49, Dave Barber  wrote:
>>
>>> **
>>> Just realised a flaw in my earlier checks - all 3 servers are in a
>>> server group, escalations can only run on one server in the group.
>>>
>>> So regardless of which server triggers the escalation process into
>>> action (setting a value on a form), the escalation will always run on the
>>> same server - and subsequently the related filters will also only run on
>>> the server nominated for escalations ...
>>>
>>> And doing these checks after having been up for about 18 hours isn't
>>> advisable 
>>>
>>> Regards
>>>
>>> Dave
>>>
>>> On 16 March 2016 at 20:26, Dave Barber  wrote:
>>>
 All 3 servers are running from the same database (ie. same codebase).

 The two solaris servers are (supposedly) identical hardware and builds
 (Solaris, Java, etc.).  The Red Hat box is totally different in almost
 every possible way (processors, memory, probably java version).  And it is
 only on one of the two Solaris boxes where the escalation fails.

 The escalation in question triggers a table loop through a list of
 impacted areas related to a change, in order to build a contact list for
 notifications.  The data set in question has around 6,500 impacted areas to
 loop through, remove duplicate customers/contacts, etc.  The actual set of
 filters triggered are best described as "complicated".  But as it runs fine
 on two of the three servers, that is why I am considering AR Server
 configuration issues - and it is easier for me to investigate and change
 such things.

 I'll check out your confdiff app Misi, much appreciated (currently
 using Notepad++ with a comparison plugin).

 Regards

 Dave

 On 16 March 2016 at 19:26,  wrote:

> Same version of Java ?
> Just wondering
>
>
> Sent from my iPhone
>
> > On Mar 16, 2016, at 2:18 PM, Misi Mladoniczky  wrote:
> >
> > Hi,
> >
> > It would be interesting to know more about what the escalation is
> actually
> > doing.

Re: Hanging escalations?

[Rod Harris]

Hi Dave,

>From what you describe it does sound like your escalation is stuck in some
kind of infinite loop. You should put filter logging on the server that is
hosting your escalation. You may find that your filters being triggered by
the escalation are never completing and perhaps timing out prior to the end
of the transaction. This may cause the transaction to roll back and for the
same condition to trigger again and again, not giving anything else a look
in. When this happens you may see very little in the escalation log for the
impacted pool.

The root cause of this may be a difference in data or configuration between
servers or may also be that the workflow is not designed to scale to
production loaded servers.

Hope this helps,

Rod Harris



On 17 March 2016 at 08:49, Dave Barber  wrote:

> **
> Just realised a flaw in my earlier checks - all 3 servers are in a server
> group, escalations can only run on one server in the group.
>
> So regardless of which server triggers the escalation process into action
> (setting a value on a form), the escalation will always run on the same
> server - and subsequently the related filters will also only run on the
> server nominated for escalations ...
>
> And doing these checks after having been up for about 18 hours isn't
> advisable 
>
> Regards
>
> Dave
>
> On 16 March 2016 at 20:26, Dave Barber  wrote:
>
>> All 3 servers are running from the same database (ie. same codebase).
>>
>> The two solaris servers are (supposedly) identical hardware and builds
>> (Solaris, Java, etc.).  The Red Hat box is totally different in almost
>> every possible way (processors, memory, probably java version).  And it is
>> only on one of the two Solaris boxes where the escalation fails.
>>
>> The escalation in question triggers a table loop through a list of
>> impacted areas related to a change, in order to build a contact list for
>> notifications.  The data set in question has around 6,500 impacted areas to
>> loop through, remove duplicate customers/contacts, etc.  The actual set of
>> filters triggered are best described as "complicated".  But as it runs fine
>> on two of the three servers, that is why I am considering AR Server
>> configuration issues - and it is easier for me to investigate and change
>> such things.
>>
>> I'll check out your confdiff app Misi, much appreciated (currently using
>> Notepad++ with a comparison plugin).
>>
>> Regards
>>
>> Dave
>>
>> On 16 March 2016 at 19:26,  wrote:
>>
>>> Same version of Java ?
>>> Just wondering
>>>
>>>
>>> Sent from my iPhone
>>>
>>> > On Mar 16, 2016, at 2:18 PM, Misi Mladoniczky  wrote:
>>> >
>>> > Hi,
>>> >
>>> > It would be interesting to know more about what the escalation is
>>> actually
>>> > doing. Number of records, what is the action, etc.
>>> >
>>> > I have a handy tool to compare config files that you can download here:
>>> > https://rrr.se/cgi/tools/main?tool=rrrConfDiff
>>> >
>>> >Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP
>>> 2011)
>>> >
>>> > Ask the Remedy Licensing Experts (Best R.O.I. Award at
>>> WWRUG10/11/12/13):
>>> > * RRR|License - Not enough Remedy licenses? Save money by optimizing.
>>> > * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy
>>> logs.
>>> > Find these products, and many free tools and utilities, at
>>> http://rrr.se.
>>> >
>>> >> All,
>>> >>
>>> >> Have an interesting one; we have an ARS 7.5/ITSM 7.6 system running
>>> on :
>>> >> 1 server RHL, used for integration/CMDB processing
>>> >> 2 servers running Solaris, in an active/passive load balanced
>>> environment,
>>> >> users will typically use either of these.
>>> >>
>>> >> Users normally connect to the server designated as primary (ie. the
>>> active).
>>> >>
>>> >> We implemented some new functionality driven from escalations - runs
>>> >> absolutely fine on our test environments, but it has started to fail
>>> on the
>>> >> active server.  And when I say "fail", I mean that all escalations
>>> just
>>> >> grind to a halt the moment when this new functionality is invoked.
>>> Nothing
>>> >> explanatory in arerror.log, I have full filter/escalation logging
>>> enabled
>>> >> (on a per thread basis), and it gives no error either - escalations
>>> just
>>> >> plain stop.
>>> >>
>>> >> What makes this interesting is that if I run this same process (same
>>> change
>>> >> request, same data, etc) via the integration server or the secondary,
>>> it
>>> >> runs without any problems.
>>> >>
>>> >> As far as I can tell we have the escalations threads setup the same
>>> on both
>>> >> of the "user" solaris servers
>>> >> Server #1 (which fails)
>>> >> Private-RPC-Socket:  390601   1   1
>>> >> Private-RPC-Socket:  390603   3   8  (escalations threads)
>>> >> Private-RPC-Socket:  390620  12  30
>>> >> Private-RPC-Socket:  390630   3   4
>>> >> Private-RPC-Socket:  390635  12  30
>>> >> Private-RPC-Socket:  390680  15  30
>>> >>
>>> >> Server #2 (which runs fine)
>>> >> Private-RPC-Socket:

Re: Confusion over AR_SERVER_INFO values as changed in the Rel 9 API - even worse with 9.1.0

[Ben Chernys]

Hi Mark,

 

Clearly.  (#define is a c statement).

 

The call with value AR_SERVER_INFO_VERSION gives you the server version - at
least that value was not renumbered J

 

Meta-Update can connect to multiple servers of different versions using a
single version of the API (as it will be one single binary).  One of its
features is making all these values available for each opened server
session.  Release 9 has introduced issues in this area due to renumbering of
values, unacceptance of previous values - even against previous versions of
the server (where with the previous version of the API they were accepted),
making previous server values unaskable (by dropping the defines), and now
this latest fiasco of not updating the API version number.

 

Cheers

Ben

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Walters, Mark
Sent: March-17-16 03:04
To: arslist@ARSLIST.ORG
Subject: Re: Confusion over AR_SERVER_INFO values as changed in the Rel 9
API - even worse with 9.1.0

 

** 

Ben,

 

I'm not 100% certain but my understanding is that the API version does not
indicate the server version but the version of the API specification - the
values below are from the ar.h file?  If so this is the API/RPC revision
level that a client built using that API will conform to.  The server will
have a corresponding max API revision number and the two will negotiate to
the highest supported by both.  If you want the server version you'll have
to make a GSI call for operation number 4.

 

If you check the API logs from a 9.1 server you should see some clients with
protocol version 23 so it looks like the C and Java APIs may be at different
levels in 9.1.

 

I've tried to put together a list of release and protocol/db versions here -
https://communities.bmc.com/docs/DOC-37267

 

Mark

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Ben Chernys
Sent: 17 March 2016 02:17
To: arslist@ARSLIST.ORG
Subject: Re: Confusion over AR_SERVER_INFO values as changed in the Rel 9
API - even worse with 9.1.0

 

** 

Well folks,

 

I'm afraid it just got a lot worse!!!

 

9.1.0 identifies itself as 9.0.0 but has a different set of AR_SERVER_INFO
values:

 

>From 9.0.0

#define AR_CURRENT_API_VERSION   21  /* current api version */

#define AR_MAX_SERVER_INFO_USED 426  /* set "highest" server info */

 

>From 9.1.0

#define AR_CURRENT_API_VERSION   21  /* current api version */

#define AR_MAX_SERVER_INFO_USED 443  /* set "highest" server info */

 

I suppose it is too late for BMC to fix this absolute mess.   How is one's
source code to differentiate between 9.0.0 and 9.1.0 - given that they both
identify themselves as the same release and given that they have different
symbols defined?  I suppose it means that AR_CURRENT_API_VERSION is NOT to
be used to identify the API release but rather AR_MAX_SERVER_INFO_USED (as
long as you don't go back far enough that that symbol is not defined) or
possibly a combination of the two symbols.

 

I have yet to look at the actual INFO values themselves and shudder to think
what I may find.

 

Cheers

Ben

 

From: Ben Chernys [ 
mailto:ben.cher...@softwaretoolhouse.com] 
Sent: March-01-16 10:24
To: 'arslist@ARSLIST.ORG'
Subject: Confusion over AR_SERVER_INFO values as changed in the Rel 9 API

 

Hi Folks,

 

I am just trying to get my head around the AR_SERVER_INFO changes introduced
in release 9.

 

ARS 9 does something not done previously with these values:  

It changes the integer in some Info values and deletes some Info values 

 

Image this scenario:  You have a release 9 API accessing a Release 8 server.

Which symbol do you use for a release 8 value?  There are no symbols for
deleted values which are still legitimate on the 8 server.  The symbol
defined in the 9 API will request the wrong value on an 8 server.

 

Similarly, you have a release 8 API accessing a release 9 server:  When you
ask for an Info that has had a number change, what do you get?

 

For now, I will have to get around the problem by not asking for contentious
info values.  Heaven forbid that someone wants these values J

 

I question how something this basic and simple could have been turned into
something this obtuse and convoluted.  I also question what the API itself
does when "maintaining compatibility" across server releases.

 

Kudos to BMC, they have maintained excellent compatibility across server
releases when it comes to the data portion of the API.  

This is the first release which does not.  Any comments from BMC would be
welcome.

 

Details:

 

Release 8.1 API

-  These are all dropped in 9:

#define AR_SERVER_INFO_MESSAGE_BROKER_URL 374 /* char - Message
Broker URL */

#define AR_SERVER_INFO_NUMBER_OF_SELECTOR_THREADS 375 /* int - Number of
selector threads. */

#define AR_SERVER_INFO_MESSAGE_BROKER_PORT376 /* int -

ARS custom Java authentication guidance

[Daniel Wu]

We are trying to create our own custom Java authentication provider. I found a 
Java authenticator sample, but there is no documentation or guideline on where 
to put those compiled jar files or the properties files. If someone has any 
documentation on the custom Java, it would be greatly appreciated.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Openfire with ARSystem 9.0

[Jennifer Varkey]

Hello Folks,
I was wondering if anyone had integrated Openfire 3.8.1 or 4.0.1 with ARS 9.0 
(no ITSM).
I have been following the documentation
https://docs.bmc.com/docs/display/public/ars81/Installing+and+configuring+the+Openfire+chat+server
and
https://docs.bmc.com/docs/display/public/ars81/Configuring+the+BMC+Remedy+AR+System+server+to+work+with+the+chat+server
I created a form with a DVF field. When i open the form in the browser, I get 
the error message "Object doesn't support this property or method". I have 
pasted the screen-capture below;




Is there something that i missed?
Is it possible to integrate ARS with Openfire?
Thanks in advance for all your help..
Cheers!!Sonia

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Confusion over AR_SERVER_INFO values as changed in the Rel 9 API - even worse with 9.1.0

[Ben Chernys]

Well folks,

 

I'm afraid it just got a lot worse!!!

 

9.1.0 identifies itself as 9.0.0 but has a different set of AR_SERVER_INFO
values:

 

>From 9.0.0

#define AR_CURRENT_API_VERSION   21  /* current api version */

#define AR_MAX_SERVER_INFO_USED 426  /* set "highest" server info */

 

>From 9.1.0

#define AR_CURRENT_API_VERSION   21  /* current api version */

#define AR_MAX_SERVER_INFO_USED 443  /* set "highest" server info */

 

I suppose it is too late for BMC to fix this absolute mess.   How is one's
source code to differentiate between 9.0.0 and 9.1.0 - given that they both
identify themselves as the same release and given that they have different
symbols defined?  I suppose it means that AR_CURRENT_API_VERSION is NOT to
be used to identify the API release but rather AR_MAX_SERVER_INFO_USED (as
long as you don't go back far enough that that symbol is not defined) or
possibly a combination of the two symbols.

 

I have yet to look at the actual INFO values themselves and shudder to think
what I may find.

 

Cheers

Ben

 

From: Ben Chernys [mailto:ben.cher...@softwaretoolhouse.com] 
Sent: March-01-16 10:24
To: 'arslist@ARSLIST.ORG'
Subject: Confusion over AR_SERVER_INFO values as changed in the Rel 9 API

 

Hi Folks,

 

I am just trying to get my head around the AR_SERVER_INFO changes introduced
in release 9.

 

ARS 9 does something not done previously with these values:  

It changes the integer in some Info values and deletes some Info values 

 

Image this scenario:  You have a release 9 API accessing a Release 8 server.

Which symbol do you use for a release 8 value?  There are no symbols for
deleted values which are still legitimate on the 8 server.  The symbol
defined in the 9 API will request the wrong value on an 8 server.

 

Similarly, you have a release 8 API accessing a release 9 server:  When you
ask for an Info that has had a number change, what do you get?

 

For now, I will have to get around the problem by not asking for contentious
info values.  Heaven forbid that someone wants these values J

 

I question how something this basic and simple could have been turned into
something this obtuse and convoluted.  I also question what the API itself
does when "maintaining compatibility" across server releases.

 

Kudos to BMC, they have maintained excellent compatibility across server
releases when it comes to the data portion of the API.  

This is the first release which does not.  Any comments from BMC would be
welcome.

 

Details:

 

Release 8.1 API

-  These are all dropped in 9:

#define AR_SERVER_INFO_MESSAGE_BROKER_URL 374 /* char - Message
Broker URL */

#define AR_SERVER_INFO_NUMBER_OF_SELECTOR_THREADS 375 /* int - Number of
selector threads. */

#define AR_SERVER_INFO_MESSAGE_BROKER_PORT376 /* int -
Messsaging(JMS) broker port. */

#define AR_SERVER_INFO_JMX_PORT   377 /* int - JMX Port */

#define AR_SERVER_INFO_PEER_LISTENER_PORT 378 /* int - (Cache)
Peer-listener-port */

-  These are renumbered in 9:

#define AR_SERVER_INFO_API_MONITORING_UPDATE_INTERVAL 379 /* int - Update
Interval for API Monitoring */

#define AR_SERVER_INFO_API_RECORDING_CLIENT_TYPE  380 /* char - API
Recording on for specific Client Type */

#define AR_SERVER_INFO_API_RECORDING_ENABLE   381 /* int - Enable Flag
would be set to T or F */

#define AR_SERVER_INFO_API_RECORDING_CLIENT_TYPE  380 /* char - API
Recording on for specific Client Type */

#define AR_SERVER_INFO_API_RECORDING_ENABLE   381 /* int - Enable Flag
would be set to T or F */

#define AR_SERVER_INFO_OBJ_RESERVATION_REPOSITORY_TYPE 382 /* int - Object
reservation repository type - 0  ARS; 10 External */

-  This value has a different meaning in 9:

#define AR_SERVER_INFO_SERVICE_RECORDING_ENABLE   383 /* int - flag to
enable the Service Monitoring */

-  Now they align with 9

#define AR_SERVER_INFO_STATS_APISQL_CONTROL   384 /* Bitmask for controlling
API/SQL display to console, exception logging option, etc. */

 

Release 9 APIRelease 9 has no 379 J

#define AR_SERVER_INFO_API_MONITORING_UPDATE_INTERVAL380  /* int -
Update Interval for API Monitoring */

#define  AR_SERVER_INFO_API_RECORDING_CLIENT_TYPE381  /* String
- API Recording on for specific Client Type */

#define  AR_SERVER_INFO_API_RECORDING_ENABLE 382  /* int -
Enable Flag would be set to T or F */

#define AR_SERVER_INFO_OBJ_RESERVATION_REPOSITORY_TYPE 383 /* int Object
reservation repository type - 0  ARS  */

   /*
- 10 External */

#define AR_SERVER_INFO_STATS_APISQL_CONTROL  384 /* bitmask  Controls
API and SQL recording */

 

 


Cheers,

Ben Chernys
Senior Software Architect
logoSthInc-sm  

Canada / Deutschland
Mobile:  +49 171 380 2329GMT + 7 + [ DST ]

Land:+1 403 240 4377
Email:
ben.

Re: Hanging escalations?

[Misi Mladoniczky]

Hi,

It would be interesting to know more about what the escalation is actually
doing. Number of records, what is the action, etc.

I have a handy tool to compare config files that you can download here:
https://rrr.se/cgi/tools/main?tool=rrrConfDiff

Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)

Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.

> All,
>
> Have an interesting one; we have an ARS 7.5/ITSM 7.6 system running on :
> 1 server RHL, used for integration/CMDB processing
> 2 servers running Solaris, in an active/passive load balanced environment,
> users will typically use either of these.
>
> Users normally connect to the server designated as primary (ie. the active).
>
> We implemented some new functionality driven from escalations - runs
> absolutely fine on our test environments, but it has started to fail on the
> active server.  And when I say "fail", I mean that all escalations just
> grind to a halt the moment when this new functionality is invoked.  Nothing
> explanatory in arerror.log, I have full filter/escalation logging enabled
> (on a per thread basis), and it gives no error either - escalations just
> plain stop.
>
> What makes this interesting is that if I run this same process (same change
> request, same data, etc) via the integration server or the secondary, it
> runs without any problems.
>
> As far as I can tell we have the escalations threads setup the same on both
> of the "user" solaris servers
> Server #1 (which fails)
> Private-RPC-Socket:  390601   1   1
> Private-RPC-Socket:  390603   3   8  (escalations threads)
> Private-RPC-Socket:  390620  12  30
> Private-RPC-Socket:  390630   3   4
> Private-RPC-Socket:  390635  12  30
> Private-RPC-Socket:  390680  15  30
>
> Server #2 (which runs fine)
> Private-RPC-Socket:  390601   1   1
> Private-RPC-Socket:  390603   3   8
> Private-RPC-Socket:  390620  12  30
> Private-RPC-Socket:  390635  12  30
> Private-RPC-Socket:  390680  15  30
>
> I am thinking of going through the various configurations in ar.conf and
> aligning the failing primary wherever possible/practical - but any hints as
> to why it could be failing welcome!
>
> Regards
>
> Dave Barber
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> "Where the Answers Are, and have been for 20 years"
>

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: User timeout triggers ARERR 9351

[Irving, Isabel (ACCESS LLP)]

The users (and developers) don't have any option other than IE - but this is a 
good idea.  I'll see if we can get FF or Chrome for testing.  

I think one part of the issue is that something is timing the users out before 
they get to the mid-tier timeout (set at 90 minutes).  This means they get a 
very unfriendly error message instead of something simple telling them their 
session has expired.

Tomcat timeout is set to 91 minutes.

-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Ludwig, Sally
Sent: 11 March 2016 17:16
To: arslist@ARSLIST.ORG
Subject: Re: User timeout triggers ARERR 9351

Does the problem occur in FF or Chrome?  If not, points to IE settings.
If it does occur in FF or Chrome, do you have the Network capture options 
there? 
Another alternative is to use Fiddler to do the network capture 
(http://www.telerik.com/fiddler) 


-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Irving, Isabel (ACCESS LLP)
Sent: Friday, March 11, 2016 10:29 AM
To: arslist@ARSLIST.ORG
Subject: Re: User timeout triggers ARERR 9351

The F12 option is greyed out for us.

One other detail I forgot to mention is that all our servers and all our users 
are WITHIN the firewall.  Does this make it less likely to be a network issue?

-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Ludwig, Sally
Sent: 11 March 2016 16:16
To: arslist@ARSLIST.ORG
Subject: Re: User timeout triggers ARERR 9351

Have you done any network captures (F12 in IE) to see what HTTP request is 
returning the 9351?   Then trace that into the detailed midtier log to see if 
there are more clues there? 


-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Irving, Isabel (ACCESS LLP)
Sent: Friday, March 11, 2016 9:57 AM
To: arslist@ARSLIST.ORG
Subject: Re: User timeout triggers ARERR 9351

Thanks for this.

We're on IE 11 and I'm not using compatibility view.  Do you think the hotfix 
will still make a difference for us?

For testing I've changed the mid-tier timeout to 5 minutes and I still get 
ARERR 9351 instead of anything more user-friendly.

-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Ludwig, Sally
Sent: 11 March 2016 14:08
To: arslist@ARSLIST.ORG
Subject: Re: User timeout triggers ARERR 9351

This defect: 
SW00492389  When session is invalid and IE10 with compatibility view is 
used, a NullPointerException is returned and user sees ARERR 9351
Is fixed in Midtier 8.1.02 Hotfix 20150911 Hotfix.
I would contact BMC Support for the latest 8.1 sp2 hotfix.

-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky
Sent: Friday, March 11, 2016 6:04 AM
To: arslist@ARSLIST.ORG
Subject: Re: User timeout triggers ARERR 9351

Hi,

Just beware, firewall people usually put up a relentless fight in order to 
prevent changes in their strategy ;-)

Best Regards - Misi, RRR AB, http://rrr.se

> Thanks Misi, I'll try that!
>
> -Original Message-
> From: Action Request System discussion list(ARSList) 
> [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky
> Sent: 11 March 2016 11:15
> To: arslist@ARSLIST.ORG
> Subject: Re: User timeout triggers ARERR 9351
>
> Hi,
>
> This seems to be a problem between the browser and Mid-Tier. 
> Presumably caused by a firewall timeout issue. Maybe you can get your 
> firewall people to look into increasing the session length in order to 
> prevent this to happen often.
>
> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP
> 2011)
>
> Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
> Find these products, and many free tools and utilities, at http://rrr.se.
>
>> Hello!
>>
>> Do you know how we can get a more user-friendly error when a session 
>> times out after 90 minutes of inactivity?
>>
>> Currently we get the following:
>>
>> "Unable to setup data connection, which is preventing the application 
>> from working correctly.  HTTP Communication Error : 500 (AR 9351)"
>>
>> We are getting quite a lot of AR 9351 and 9350 errors but I think 
>> some of the time it is just a timeout, and this error message is 
>> making users think that there is something wrong with the application.
>>
>> We have mid-tier 8.1.SP02 Patch 001 201505281150 Hotfix.  It's a 
>> totally bespoke solution.
>>
>> Full server details below.
>> Thanks
>> Isabel
>>
>>
>> Server Information
>> Application server version: 8.1.00 201301251157
>> Hardware: sun4v
>> Operating system: SunOS 5.10
>> On Sun 

Re: ARS custom Java authentication guidance

[laurent matheo]

Hi Daniel,

The mid-tier part is explained in the doc wiki at this url:
https://docs.bmc.com/docs/display/public/ars201401/Integrating+the+mid+tier+into+an+SSO+environment

To sum it up, it's kinda like this:
-> copy your authenticator jar file (and libs if needed) in "/WEB-INF/lib/" 
from the mid-tier,
-> copy your authenticator properties file (let's say "myauthenticator.properties") into 
"/WEB-INF/classes/" from mid-tier,
-> config BMC "/WEB-INF/classes/config.properties" to tell to use your 
authenticator:
--> arsystem.authenticator=YourAuthenticatorPackage.YourAuthenticatorClass
--> arsystem.authenticator.config.file=myauthenticator.properties
--> I did not have to change "arsystem.authenticator.sso.enckey" when I did 
mine for Engage 2014,

That's pretty much all Mid-Tier side...

I did an authenticator plugin and AREA plugin and videos for the BMC Engage 
2014 but I don't think I can post it here since it's something dedicated for 
BMC Engage (same as for wwrug I guess we are not expected to share it to people 
who did not attend)...

Was the question only for Mid-Tier or also ARS side?

Best regards.

Laurent.


Best regards.


Laurent.


On 17 Mar, 2016, at 11:48 AM, Daniel Wu  wrote:

We are trying to create our own custom Java authentication provider. I found a 
Java authenticator sample, but there is no documentation or guideline on where 
to put those compiled jar files or the properties files. If someone has any 
documentation on the custom Java, it would be greatly appreciated.

___
UNSUBSCRIBE or access ARSlist Archives at http://www.arslist.org
"Where the Answers Are, and have been for 20 years"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

BMC Remedy Skype Intergration

[BradRemedy]

Hi

Has anyone integrated Skype with BMC Remedy at all? We are looking into
options in which a chat conversation could be started for a call and the
chat log is added as a work info to a ticket when the chat is finished.

I am busy investigating options however wanted to know if anyone else has
done this sort of integration before.

Thanks in advance

Brad

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: BMC Remedy Skype Intergration

[Jamie]

Hello Fred,

I was interested in your comment where you said you can launch a chat window 
with Skype/Lync using SIP://emailaddress.  However, when I reached out to my 
exchange team that supports our Skype/Lync platform, they weren't aware of this 
capability and aren't sure how it can be done.  Can you provide a little more 
information on this?

Thanks!
Jamie

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Hanging escalations?

[Dave Barber]

All 3 servers are running from the same database (ie. same codebase).

The two solaris servers are (supposedly) identical hardware and builds
(Solaris, Java, etc.).  The Red Hat box is totally different in almost
every possible way (processors, memory, probably java version).  And it is
only on one of the two Solaris boxes where the escalation fails.

The escalation in question triggers a table loop through a list of impacted
areas related to a change, in order to build a contact list for
notifications.  The data set in question has around 6,500 impacted areas to
loop through, remove duplicate customers/contacts, etc.  The actual set of
filters triggered are best described as "complicated".  But as it runs fine
on two of the three servers, that is why I am considering AR Server
configuration issues - and it is easier for me to investigate and change
such things.

I'll check out your confdiff app Misi, much appreciated (currently using
Notepad++ with a comparison plugin).

Regards

Dave

On 16 March 2016 at 19:26,  wrote:

> Same version of Java ?
> Just wondering
>
>
> Sent from my iPhone
>
> > On Mar 16, 2016, at 2:18 PM, Misi Mladoniczky  wrote:
> >
> > Hi,
> >
> > It would be interesting to know more about what the escalation is
> actually
> > doing. Number of records, what is the action, etc.
> >
> > I have a handy tool to compare config files that you can download here:
> > https://rrr.se/cgi/tools/main?tool=rrrConfDiff
> >
> >Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
> >
> > Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
> > * RRR|License - Not enough Remedy licenses? Save money by optimizing.
> > * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
> > Find these products, and many free tools and utilities, at http://rrr.se
> .
> >
> >> All,
> >>
> >> Have an interesting one; we have an ARS 7.5/ITSM 7.6 system running on :
> >> 1 server RHL, used for integration/CMDB processing
> >> 2 servers running Solaris, in an active/passive load balanced
> environment,
> >> users will typically use either of these.
> >>
> >> Users normally connect to the server designated as primary (ie. the
> active).
> >>
> >> We implemented some new functionality driven from escalations - runs
> >> absolutely fine on our test environments, but it has started to fail on
> the
> >> active server.  And when I say "fail", I mean that all escalations just
> >> grind to a halt the moment when this new functionality is invoked.
> Nothing
> >> explanatory in arerror.log, I have full filter/escalation logging
> enabled
> >> (on a per thread basis), and it gives no error either - escalations just
> >> plain stop.
> >>
> >> What makes this interesting is that if I run this same process (same
> change
> >> request, same data, etc) via the integration server or the secondary, it
> >> runs without any problems.
> >>
> >> As far as I can tell we have the escalations threads setup the same on
> both
> >> of the "user" solaris servers
> >> Server #1 (which fails)
> >> Private-RPC-Socket:  390601   1   1
> >> Private-RPC-Socket:  390603   3   8  (escalations threads)
> >> Private-RPC-Socket:  390620  12  30
> >> Private-RPC-Socket:  390630   3   4
> >> Private-RPC-Socket:  390635  12  30
> >> Private-RPC-Socket:  390680  15  30
> >>
> >> Server #2 (which runs fine)
> >> Private-RPC-Socket:  390601   1   1
> >> Private-RPC-Socket:  390603   3   8
> >> Private-RPC-Socket:  390620  12  30
> >> Private-RPC-Socket:  390635  12  30
> >> Private-RPC-Socket:  390680  15  30
> >>
> >> I am thinking of going through the various configurations in ar.conf and
> >> aligning the failing primary wherever possible/practical - but any
> hints as
> >> to why it could be failing welcome!
> >>
> >> Regards
> >>
> >> Dave Barber
> >>
> >>
> ___
> >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> >> "Where the Answers Are, and have been for 20 years"
> >
> >
> ___
> > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> > "Where the Answers Are, and have been for 20 years"
>
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> "Where the Answers Are, and have been for 20 years"
>

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Confusion over AR_SERVER_INFO values as changed in the Rel 9 API - even worse with 9.1.0

[Ben Chernys]

Hi Doug,

 

Thanks for your response.  I am well aware of when the API version changes - I 
make a single binary in various API releases though I only tend to have 
customers on a single release of the API - generally the most current.  I only 
recently dropped pre 7 releases from the build.

 

I use the API version at compile time - as would be expected.  Consider compile 
time for a moment.  How does one ask for a value against the 8.1 server using 
the 9.1 API when that define is dropped in the 9.1 API or when that define has 
a different integer in the 9.1 API?  

 

Consider that the MAX for 9.1 and 9.0 are different even though the API version 
is the same.  Consider also that the API version for 9.1 is not the same value 
in Java.  See Mark Walters' email in this thread.  

 

It would seem the 9.0.1 api increased in by 1 in java as did the 9.1.0 API but 
that increase was missed in the C API/header files.  I certainly cannot comment 
on why defines were renumbered from 8.1.2 to 9.

 

I have a table of the INFO values to my max at compile time with an indicator 
of whether they are readable and/or writable.  (By the way, the readable / 
writable attributes would be good to have from BMC).  I also have a table of 
MAX values based on server release.  

 

I use the two tables to build the readable set of values per server connection 
(using the server release as a MAX) and then get the complete set of responses. 
 (Yes, I make a smaller previous call to get server name, release, and a few 
other values to be used internally.)

 

So, yes, I suspect errors have been made.  As all software have errors made in 
them.  No software vendor/creator is immune from errors.  Just ask my wife 
about why she doesn’t want any robots in the house J

 

Thanks again,

Ben

 

 

-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Mueller, Doug
Sent: March-17-16 10:14
To: arslist@ARSLIST.ORG
Subject: Re: Confusion over AR_SERVER_INFO values as changed in the Rel 9 API - 
even worse with 9.1.0

 

Ben,

 

There needs to be an overall look at the issues you are having -- please submit 
the issues and concerns to the support team and they can be investigated.  
There is always the chance that an error was made that needs to be corrected 
and that will definitely be looked into and action taken to correct the problem.

 

But, I want to pursue the topic of API version that you have brought up in your 
recent messages.

 

API version != product version

 

We sometimes change the API version multiple times between releases.  We 
sometimes change the API version for a maintenance release.  We sometimes don't 
change the API version for a maintenance release and there are occasions where 
the API version may not change for a release.  It is all about the API version 
and whether there was a notable change made such that we have to map the 
protocol between clients and servers of different versions.

 

If you are using the API version as a product release version, that is 
incorrect and will not work.  We do not always change the API even when there 
are new releases.  Yes, it changes with many releases, but not with ALL 
releases.

 

To tell what release you are using, you should be using AR_SERVER_INFO_VERSION  
 (code 4).  This will give you the version of the server and it includes 
details about version and service pack and patch.  THIS will be changed in each 
release for sure --- well I sure hope you find it being different between 
releases as it sure is supposed to be different.

 

I just want to be sure that the right value is being used for the right 
purpose.  I am concerned and want to find out why you have found some 
differences in the server information results returned -- that is not supposed 
to happen.  I also want to be sure you are using the right setting for the 
right purpose.   On the other hand, I want to be sure you are not misusing the 
API version to determine server version -- they are not the same thing.  Now, 
did 9.1 change the API protocol?  And, should the number have changed from 
server info?  That can be double checked, but it very well may not have changed.

 

I hope this helps,

 

Doug Mueller

 

-Original Message-

From: Action Request System discussion list(ARSList) [ 
 mailto:arslist@ARSLIST.ORG] On Behalf Of Ben 
Chernys

Sent: Thursday, March 17, 2016 7:21 AM

To:   arslist@ARSLIST.ORG

Subject: Re: Confusion over AR_SERVER_INFO values as changed in the Rel 9 API - 
even worse with 9.1.0

 

Hi Misi,

 

Not true re keeping the c API up-to-date.  BMC still delivers many binaries 
with the c API (in both 32 and 64 bits) in the 9.1.0 installation.  And the 
point is beyond BMC anyhow.  They publish it and it should work.  It should 
also allow a higher API to communicate with lower servers.

 

Cheers

Ben

 

-Original Message

Re: Issue with the Web Services in BMC Remedy 7.6.04

[Julia James]

Have you tried looking at the code?  I know it's a long shot but we had a web 
service that timed out.  It turned out that there was a character limitation of 
240 and the sender had it programmed so the user could only enter 240 to send.  
They must have been sending an extra character because I changed the filter to 
create the transaction to limit the value to Left 240 on the Remedy side and it 
took care of the problem.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Turn off AREA LDAP Polling?

[Sinclair, Keith]

Never mind. I found it.

For those of you who are wondering -

On the EA tab in the Server Information Configuration form, you'll see a box 
called "Need To Sync". If this is set to 0, Remedy won't periodically make AD 
checks.

From: Sinclair, Keith
Sent: Wednesday, March 16, 2016 8:58 AM
To: arslist@ARSLIST.ORG
Subject: Turn off AREA LDAP Polling?

If I recall correctly, there is a way to tell Remedy to not make periodic AD 
checks every so often with a user's account that signed into Remedy using AREA 
LDAP but for the life of me, I cannot remember how or where it's done.

Anyone know where the setting is at?

Keith Sinclair
Remedy Development
ShopperTrak Chicago, USA
O 312.676.8289
ksincl...@shoppertrak.com | shoppertrak.com
Retail Profitability, Improved.


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"