Re: $OPERATION$ keyword w/Modify All

[Mike Galat]

Hi Dustin –

It may have to do with where in the process you are actually capturing the 
operation.  I have a small test form, and I created three active links, one to 
fire on Display, one on Window Open, and one on Window Loaded.  The active link 
simply displayed  operation: $OPERATION$ in the prompt bar.  
Here is what I found, (one small caveat – we run 8.1.02):

Open in new mode:
Window Open operation: CREATE (ARNOTE 1)
Window Loaded operation: CREATE (ARNOTE 1)

Open in Search mode:
Window Open operation: QUERY (ARNOTE 1)
Window Loaded operation: QUERY (ARNOTE 1)

Perform a search:
Display operation: SET (ARNOTE 1)

Select all, then click Modify All:
Window Open operation: SET ALL (ARNOTE 1)

Your mileage may vary!

Thanks,

Michael Galat


From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Jason Miller
Sent: Saturday, October 14, 2017 03:30
To: arslist@ARSLIST.ORG
Subject: Re: $OPERATION$ keyword w/Modify All

**
Is the button really being set to Submit Ticket on Modify All because the 
$OPERATION$ is inaccurately resolving to CREATE or just because that is the 
default text of the button?

Did you try using "SET ALL" for the $OPERATION$ comparison?

https://docs.bmc.com/docs/ars91/keywords-609072326.html#Keywords-Keywords

Jason



On Fri, Oct 13, 2017 at 4:39 PM, Fawver, Dustin 
mailto:faw...@mail.etsu.edu>> wrote:
**
Greetings!

I have a form in ARS 9.1.02 where I’ve created a button to commit changes when 
either creating or modifying a request.  I use the $OPERATION$ keyword to 
determine what mode I’m in.  I change the label on the button to read “Submit 
Ticket” for new requests, and to “Update Ticket” when modifying a request.  
When I select multiple requests at once and choose “Modify All”, it appears 
that the value for $OPERATION$ is being set to “Create”, so the button reads 
“Submit Ticket”.  While the operation still works as expected when clicking the 
button, I’d like to make the button label read “Update All” in those cases.
Thanks!
Dustin Fawver
Sr. Help Desk Technician
Information Technology Services

P: 423-439-4648
itsh...@etsu.edu
[itslogo]

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

_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: Best way to delete records

[Mike Galat]

Hi Kelly –

I am sure LJ’s tool will work, just wanted to point out what we did in the 
past.  We have used rrrChive (a free utility) to remove a lot of tickets (we 
are not an ITSM shop, most everything custom).  What we did, was use the MOVE 
functionality, give it an ARX file to dump it to, and no receiveing system for 
it to go to.  The end result was arx files, along with attachments, etc. that 
were dumped to a server.  Our use-case was to archive the data on the server 
for a year, then delete, however if you don’t care about the data, you can 
simply delete the arx and subfolders.

Thanks,
Mike

From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of Kelly Logan
Sent: Friday, December 08, 2017 12:05
To: ARSList
Subject: Re: Best way to delete records

I will check it out, LJ - thanks!

On Fri, Dec 8, 2017 at 9:55 AM, LJ LongWing 
mailto:lj.longw...@gmail.com>> wrote:
Kelly,
I have a tool on my website (http://remedylegacy.com/tools/delete-requests/) 
that might do what you want.  It's designed to allow you to issue SQL Queries 
to identify records that need to be removed, and then removes them via the api. 
 You could in theory issue a query to say the task form and say give me a list 
of all tasks that are associated with incidents I want to remove...and it'll 
remove those tasksyou of course would want to remove all of the children 
before the parents...or, alternatively you could use this tool to delete all of 
the parents first, and then do an sql query on the children records and delete 
any orphans that were left behind...

On Fri, Dec 8, 2017 at 8:40 AM, Kelly Logan 
mailto:kelly.lo...@raptek.com>> wrote:
We are working on a mass delete system as well, to remove a section of data 
belonging to one group. In addition to the concerns of the mass delete of a 
number of records, I am also looking for an efficient way to remove their 
child/transactional records as well. While the parent records can be found with 
a simple query on the company name, this field is not on most of the related 
records. Instead I am left with a list of parent record ids. I am looking at 
ways to feed these in process-able chunks to other delete commands for the 
related records.

I am looking for the fastest and least error-prone method on ITSM 8.1 as this 
will likely need to run during a maintenance window.

Any advice on what deletion processes are the most efficient and/or handy 
tricks to clear out related entries using other methods? I am currently 
considering workflow, Pentaho Spoon and workflow generated SQL.

Also, any references for ITSM 8.1 data models (an ERD for each of the 
applications would be really handy) would be greatly appreciated.


On Fri, Dec 8, 2017 at 8:34 AM, Pattabiraman, Vishal 
mailto:vishal.pattabira...@cgi.com>> wrote:
Hi,

I had worked on a requirement were we had to purge records. What we did was, 
take SQL logs and check all the dependent tables that gets affected.
Create a SQL job that mimics the same functionality and include it in Scheduled 
job. The best part of this solution was, it was powerful and silent. No ARS 
service downtime.
Hope this helps.

Thanks!
Vishal

From: ARSList 
[mailto:arslist-boun...@arslist.org] On 
Behalf Of Arner, Todd
Sent: Friday, December 08, 2017 7:50 PM
To: arslist@ARSLIST.ORG
Subject: Best way to delete records

We have a form in Remedy that we upload user access information into on a 
bi-weekly basis. (There is about 300,000 rows)  Prior to uploading the data to 
the form,  we delete all of the current records and then upload the new data.  
We have been using the Application-Query-Delete-Entry in an escalation Run 
process to delete the records.  This process worked fine in version 8.1 but has 
stopped working in version 9.1.3.  I did find an issue related to the 
Application-Query-Delete-Entry causing a memory leak which causes the deletion 
to fail.  It was supposed to have been fixed in patch 1 but we are still seeing 
the issue after installing the patch.  Which brings me to my question, is there 
a better way to delete all the records other than using the 
Application-Query-Delete-Entry?  As a work around for now we set up a job on 
the SQL server to truncate the data but I am not sure that is a good work 
around.  I appreciate any suggestions.

Thanks,
Todd Arner
Great Lakes

The information contained in this communication may be confidential, is 
intended only for the use of the recipient(s) named above, and may be protected 
under state or federal law. If the reader of this message is not the intended 
recipient, you are hereby notified that any dissemination, distribution, or 
copying of this communication, or any of its contents, is strictly prohibited. 
If you have received this communication in error, please forward the 
communication to no...@glhec.org immediately and 
destroy or delete the original mes

9.1.x Notify Action Delivery Mechanism

[Mike Galat]

Hi -

We are currently working toward upgrading from AR System 8.1.02 to 9.1.03/(or 
9.1.04).  Currently our lab server is running 9.1.03.  We are running into an 
issue with the Notify action in Filters.

The Notify Delivery Mechanism allows a few values:

1: Alert
2: Email
3: User Profile Default
99: Cross-Reference

For cross reference, you can then pass an integer value to define the delivery 
mechanism at runtime:

0: No delivery
1: Alert
2: Email
3: User Profile Default

By running some filter logging we have narrowed down the types of delivery 
mechanisms that succeed/fail.  It has been our experience with 9.1 that using:


* User Profile Default (3) or Cross-Reference, with User Profile 
Default (99/dynamic 3) SUCCEEDS.

* Email (2) or Cross-Reference, with Email  (99/dynamic 2) works FAILS.

What I mean by succeeds or fails is this:

When it succeeds, the email goes out, and all variables in the subject and text 
get expanded.  So suppose I send a notification for a ticket being opened User 
Profile Default, and the subject has
$Ticket #$ has been opened at $Create Date/Time$
The email's subject will contain:
"PT-123456 - has been opened at - 1/1/2018 09:04:36 AM"

When it fails, the email goes out, and all variables in the subject and text DO 
NOT get expanded.  So suppose I send the same notification for a ticket being 
opened, using Email delivery mechanism, and the subject has
$Ticket #$ has been opened at $Create Date/Time$
The email's subject will contain:
"  - has been opened at -  "

Has anyone else experienced this behavior.  If so, were you able to fix it, and 
how?  Note: changing the notify mechanism is not an option, as we use email in 
many filters.  All of this works just fine for us in Remedy 8.1.02

Thanks!

Mike Galat


-- 
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist

RE: 9.1.x Notify Action Delivery Mechanism

[Mike Galat]

Hi RJ –

First, this all worked in 8.1.02.  We are also going against custom forms, and 
the fields that we are using in the notifications typically have a permission 
of “Public:View”.

As far as sending to email addresses, the email addresses may or may not be 
defined to the User form.  We have our own custom people form which contains 
our profiles.  In that form is the email address.  If we are sending to a 
requester, that person is likely not a Remedy login user (read no User form 
record, etc.)  According to the BMC 9.1 documentation, this should be 
supported.  See:

https://docs.bmc.com/docs/ars91/en/creating-a-notify-action-609072091.html

User notification method email:
Email — The notification is sent to the specified recipients by email. You can 
identify BMC Remedy AR System server recipients by their BMC Remedy AR System 
user or group names, [or enter email addresses to notify any recipient inside 
or outside of BMC Remedy AR System server].

Thanks,

From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of LJ LongWing
Sent: Thursday, January 11, 2018 12:39
To: ARSList
Subject: Re: 9.1.x Notify Action Delivery Mechanism

Mike,
Who is the recipient of the notification, is it a user name (value in login id 
field), or is it an email address?  If it's an email address, are there more 
than one users in the system with that email address.  If there are, if you 
send it to an email of a user with only one user account associateddoes 
that user have permissions to the fields in question?

On Thu, Jan 11, 2018 at 10:30 AM, Mike Galat 
mailto:michael.ga...@caretech.com>> wrote:
Hi –

We are currently working toward upgrading from AR System 8.1.02 to 9.1.03/(or 
9.1.04).  Currently our lab server is running 9.1.03.  We are running into an 
issue with the Notify action in Filters.

The Notify Delivery Mechanism allows a few values:

1: Alert
2: Email
3: User Profile Default
99: Cross-Reference

For cross reference, you can then pass an integer value to define the delivery 
mechanism at runtime:

0: No delivery
1: Alert
2: Email
3: User Profile Default

By running some filter logging we have narrowed down the types of delivery 
mechanisms that succeed/fail.  It has been our experience with 9.1 that using:


• User Profile Default (3) or Cross-Reference, with User Profile 
Default (99/dynamic 3) SUCCEEDS.

• Email (2) or Cross-Reference, with Email  (99/dynamic 2) works FAILS.

What I mean by succeeds or fails is this:

When it succeeds, the email goes out, and all variables in the subject and text 
get expanded.  So suppose I send a notification for a ticket being opened User 
Profile Default, and the subject has
$Ticket #$ has been opened at $Create Date/Time$
The email’s subject will contain:
“PT-123456 - has been opened at - 1/1/2018 09:04:36 AM”

When it fails, the email goes out, and all variables in the subject and text DO 
NOT get expanded.  So suppose I send the same notification for a ticket being 
opened, using Email delivery mechanism, and the subject has
$Ticket #$ has been opened at $Create Date/Time$
The email’s subject will contain:
“  - has been opened at -  “

Has anyone else experienced this behavior.  If so, were you able to fix it, and 
how?  Note: changing the notify mechanism is not an option, as we use email in 
many filters.  All of this works just fine for us in Remedy 8.1.02

Thanks!

Mike Galat



--
ARSList mailing list
ARSList@arslist.org<mailto:ARSList@arslist.org>
https://mailman.rrr.se/cgi/listinfo/arslist

-- 
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist

RE: 9.1.x Notify Action Delivery Mechanism

[Mike Galat]

Thanks for the info LJ!

Mike

From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of LJ LongWing
Sent: Thursday, January 11, 2018 14:45
To: ARSList
Subject: Re: 9.1.x Notify Action Delivery Mechanism

Mark,
Yesvarious versions of Remedy have had permissions issues over the years 
and each successive version of Remedy tries to plug holes that the previous 
version had...so, in your situation, sending to an email address instead of a 
user, you must make sure that the permission 'trail' is clearhere is the 
trail you must make sure is available to the 'Public' group

Application - If the form in question is part of an application, you must make 
sure that the public has access to it
Form - The form must have public permission
Record - Each record has row level restrictions, so you must allow all users 
access to the row in question
Field - To access the data, the user must obviously have access to it

I saw the post from Todd regarding ignoring form permissionsbut I'm not 
sure I personally like that optionsimply stated, if you are sending 
information out of a Remedy system to an 'unknown' user, then that unknown user 
should have access to all of that data to be able to get at itif you don't 
have Public permission at the Application/Form/Record/Field levels, then the 
unknown user doesn't have access to the data, and shouldn't be able to get 
access to it through email

I know that's a tough stance, but that's the stance that Remedy must make to 
ensure that truly sensitive information isn't accidentally leaked.

On Thu, Jan 11, 2018 at 11:17 AM, Mike Galat 
mailto:michael.ga...@caretech.com>> wrote:
Hi RJ –

First, this all worked in 8.1.02.  We are also going against custom forms, and 
the fields that we are using in the notifications typically have a permission 
of “Public:View”.

As far as sending to email addresses, the email addresses may or may not be 
defined to the User form.  We have our own custom people form which contains 
our profiles.  In that form is the email address.  If we are sending to a 
requester, that person is likely not a Remedy login user (read no User form 
record, etc.)  According to the BMC 9.1 documentation, this should be 
supported.  See:

https://docs.bmc.com/docs/ars91/en/creating-a-notify-action-609072091.html

User notification method email:
Email — The notification is sent to the specified recipients by email. You can 
identify BMC Remedy AR System server recipients by their BMC Remedy AR System 
user or group names, [or enter email addresses to notify any recipient inside 
or outside of BMC Remedy AR System server].

Thanks,

From: ARSList 
[mailto:arslist-boun...@arslist.org<mailto:arslist-boun...@arslist.org>] On 
Behalf Of LJ LongWing
Sent: Thursday, January 11, 2018 12:39
To: ARSList
Subject: Re: 9.1.x Notify Action Delivery Mechanism

Mike,
Who is the recipient of the notification, is it a user name (value in login id 
field), or is it an email address?  If it's an email address, are there more 
than one users in the system with that email address.  If there are, if you 
send it to an email of a user with only one user account associateddoes 
that user have permissions to the fields in question?

On Thu, Jan 11, 2018 at 10:30 AM, Mike Galat 
mailto:michael.ga...@caretech.com>> wrote:
Hi –

We are currently working toward upgrading from AR System 8.1.02 to 9.1.03/(or 
9.1.04).  Currently our lab server is running 9.1.03.  We are running into an 
issue with the Notify action in Filters.

The Notify Delivery Mechanism allows a few values:

1: Alert
2: Email
3: User Profile Default
99: Cross-Reference

For cross reference, you can then pass an integer value to define the delivery 
mechanism at runtime:

0: No delivery
1: Alert
2: Email
3: User Profile Default

By running some filter logging we have narrowed down the types of delivery 
mechanisms that succeed/fail.  It has been our experience with 9.1 that using:


• User Profile Default (3) or Cross-Reference, with User Profile 
Default (99/dynamic 3) SUCCEEDS.

• Email (2) or Cross-Reference, with Email  (99/dynamic 2) works FAILS.

What I mean by succeeds or fails is this:

When it succeeds, the email goes out, and all variables in the subject and text 
get expanded.  So suppose I send a notification for a ticket being opened User 
Profile Default, and the subject has
$Ticket #$ has been opened at $Create Date/Time$
The email’s subject will contain:
“PT-123456 - has been opened at - 1/1/2018 09:04:36 AM”

When it fails, the email goes out, and all variables in the subject and text DO 
NOT get expanded.  So suppose I send the same notification for a ticket being 
opened, using Email delivery mechanism, and the subject has
$Ticket #$ has been opened at $Create Date/Time$
The email’s subject will contain:
“  - has been opened at -  “

Has anyone else experienced this behavior

RE: Filter Firing

[Mike Galat]

Hi Brian -

It has always been my experience that filters run on that initiated them.  So, 
if initiated by an end user due to an action they took, filters would run on 
the AR server that they are connected to at the time.  Filters that are 
initiated due to an escalation would run on the server where escalations are 
configured (via the ranking form for a server group).

Thanks,
Mike



From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of Brian Pancia
Sent: Friday, January 12, 2018 13:55
To: arslist@ARSLIST.ORG
Subject: Filter Firing


Where do filters fire in a server group and can this be controlled?  I'm 
assuming they fire on the server the user is attached to at the time.  What 
about when an escalation triggers a filter.  Does the filter fire on the same 
server as the escalation, which could then be controlled in the server ranking 
form.  I never gave much thought to this.  I'm sure some basic logging will 
give me the answer.  However, looking to see if anyone has experience with this 
in a server group.  This is looking at performance enhancements to integrations 
and data imports that could have a lot of updates, which could definitely 
impact the system(s).  This seems to have more of an impact at the application 
layer rather than the database layer.



One scenario I am looking at now is that 1 million records are imported into 
the system that may update multiple records throughout the system based on 
various conditions.  If I fire the filters on import, the import could take a 
long time.  If I surpress the filters then the import runs fairly quickly given 
the number of records somewhere around an hour for 1 million records.  I could 
hold off on firing the filters until a time when utilization is low in order to 
have minimal impact on users.  On import a record could say I need to update 
Bob, Sue, Kim, and Steve with the information or any combination.  I'm sure an 
option is to have Bob as the keeper of info and have the others periodically 
check in  with Bob through escalations in order to minimize filter firing.  It 
still leaves me wondering were do filters fire and can this be controlled.  
I've always stay cleared of too many escalations.  However, when your dealing 
with large data does it make sense to chunk it into buckets using escalations 
instead of running filters?



Thanks



Brian


DISCLAIMER: The information contained in this e-mail and its attachments 
contain confidential information belonging to the sender, which is legally 
privileged. The information is intended only for the use of the recipient(s) 
named above. If you are not the intended recipient, you are notified that any 
disclosure, copying, distribution or action in reliance upon the contents of 
the information transmitted is strictly prohibited. If you have received this 
information in error, please delete it immediately.
-- 
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist

Java Plugins - running out of memory

[Mike Galat]

Hi Lister's -

We are currently on 8.1.02 (working on upgrading to 9.1.4).  It seems like our 
Java plugins are being used more and more, with thinks like webservices, RKM, 
AI, etc., and we have been seeing an increasing numbers of memory errors in the 
arjavaplugin.log. Error such as:

2018-04-25 07:10:04,137 ERROR [pool-3-thread-2] 
com.bmc.arsys.pluginsvr.plugins.a (?:?) - getListEntryWithFields() FAILs in 
plugin: RMDY.ITSM.RKM.FILESYSTEM
java.lang.RuntimeException: Failed to get File System sources from 
[RKM:FileSystemSource]form.
at 
com.bmc.itsm.rkm.ardbc.filesystem.helpers.ArHelper.getArSources(ArHelper.java:85)
at 
com.bmc.itsm.rkm.ardbc.filesystem.RkmFileSystemPlugin.getListEntryWithFields(RkmFileSystemPlugin.java:198)
at com.bmc.arsys.pluginsvr.plugins.a.ArdbcGlewf(Unknown Source)
at com.bmc.arsys.pluginsvr.a.ArEsArdbcGlewf_5(Unknown Source)
at com.bmc.arsys.pluginsvr.a.ArEsArdbcGlewf_4(Unknown Source)
at 
com.bmc.arsys.arrpc.ARPluginServerDispatcher.dispatchOncRpcCall(Unknown Source)
at 
com.bmc.arsys.arrpc.nio.ArRpcCallHandler.dispatchCall(Unknown Source)
at com.bmc.arsys.arrpc.nio.ArRpcCallHandler.if(Unknown Source)
at 
com.bmc.arsys.arrpc.nio.ArRpcCallHandler.processRpcCall(Unknown Source)
at 
com.bmc.arsys.arrpc.nio.ArRpcCallHandler$Processor.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown 
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown 
Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.OutOfMemoryError: Java heap space

2018-04-25 07:32:23,034 ERROR [pool-3-thread-16] 
com.bmc.arsys.pluginsvr.plugins.a (?:?) - getListEntryWithFields() FAILs in 
plugin: ARSYS.ARDBC.PENTAHO
java.lang.OutOfMemoryError: GC overhead limit exceeded

2018-04-25 07:32:35,349 ERROR [Thread-246] com.bmc.arsys.pluginsvr.d.b (?:?) - 
Plugin Termination Error
java.lang.OutOfMemoryError: GC overhead limit exceeded

2018-04-25 07:36:41,910 ERROR [pool-1-thread-2] 
com.bmc.arsys.arrpc.nio.ArSelectorThread (?:?) - Exception in selector thread 
loop. Shutting down selector thread10
java.lang.OutOfMemoryError: GC overhead limit exceeded
at java.util.ArrayList.iterator(Unknown Source)
at sun.nio.ch.WindowsSelectorImpl.updateSelectedKeys(Unknown 
Source)
at sun.nio.ch.WindowsSelectorImpl.doSelect(Unknown Source)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(Unknown Source)
at sun.nio.ch.SelectorImpl.select(Unknown Source)
at sun.nio.ch.SelectorImpl.select(Unknown Source)
at com.bmc.arsys.arrpc.nio.ArSelectorThread.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown 
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown 
Source)
at java.lang.Thread.run(Unknown Source)

We are currently on Java 1.7.0_45, and what we have for memory sizes in the 
armonitor.cfg are:

Java Plugin

-Xmx

-XX:PermSize

-XX:MaxPermSize

D:\Program Files\BMC Software\ARSystem\pluginsvr

2048m

128m

128m

D:\Program Files\BMC Software\ARSystem\pluginsvr\fts\primary

1024m

D:\Program Files\BMC Software\ARSystem\pluginsvr\fts\secondary

1024m

D:\Program Files\BMC Software\ARSystem\diserver\data-integration

1024m

D:\Program Files\BMC Software\ARSystem\assignmentengine\bin

256m

D:\Program Files\BMC Software\AtriumCore\cmdb\plugins\ne

512m

D:\Program Files\BMC Software\AtriumCore\cmdb\plugins\shared

512m


Are these errors indicative of not giving enough memory (fixing by increasing 
the -Xmx?)

Or do I need to set more options, such as -XX:+UseConcMarkSweepGC  and/or 
-XX:+UseParNewGC in armonitor.cfg, such as, for the primary pluginsvr:

"D:\Program Files\Java\jre7\bin\java" -Xmx2048m -XX:PermSize=128m 
-XX:MaxPermSize=128m XX:+UseConcMarkSweepGC -XX:+UseParNewGC

Any suggestions would be welcome!

Thanks,
-- 
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist

RE: Mid tier on one, AR Server on another

[Mike Galat]

Hi Dave/Jason –

We have been running 18.08.01 MT (just the standard install, not a WAR 
deployment,) first against our 8.1.02 AR Server, and then against 18.08.00 – 
since about 4/7.  One thing we noticed is we would have certain menus 
items/buttons, etc. not show up if they were to be hidden/displayed by 
permissions.  When we were on 8.1.02, we were told, the workaround is to run 
with Preload on the midtiers, which we did, of course that makes flushing 
excruciatingly slow.  We were told that once we upgrade the back end, we could 
go back to not having preload enabled.  We tried this in our lab environment, 
and still found that with 18.08.01 MT, and 18.08.00 ARS we would still loose 
elements if preload was not enabled.  We would really like to get away from 
preload.  Although you may want to enable it, do a hard flush, and see if your 
missing elements magically reappear.

Jason – Is this parameter getting pulled from central config still an issue 
with 18.08.01?  What was the parameter?

Thanks,

MIke


From: ARSList  On Behalf Of Jason Miller
Sent: Friday, March 08, 2019 10:55
To: ARSList 
Subject: Re: Mid tier on one, AR Server on another

Yes, I have used 9.1.03, 9.1.04 and 18.08 against our non-prod 9.1.02 AR 
servers. The only issue we saw was with 9.1.04 and dreadful performance. There 
was some parameter in config.properties that would get pulled from central 
config (so it affected a fresh .war deployment) that would make form load times 
excruciating, even after pre-loading. Once we figured this out, we created a 
new Cluster ID right after getting a fresh MT up and running, which prevented 
the old configuration from being pull from the DB. Worked great once we 
manually re-configured.

Jason

On Fri, Mar 8, 2019 at 5:24 AM Dave Barber 
mailto:daddy.bar...@gmail.com>> wrote:
Shortly after messaging, I experienced similar - 9.1.04 p002 was supposed to 
fix these problems.

We have a mixture of in-house applications and lightly modified OOTB, and it is 
normally the work detail tab that disappears, along with a few fields and 
buttons of our own.

Has anyone ever tried the 18.05 or 18.08 mid tiers against a 9.1.02 AR Server?  
(I'm grasping at straws, our mid tiers are a continual pain during migrations, 
but the amount of pain varies randomly)

On Wed, 6 Mar 2019 at 16:45, Jason Miller 
mailto:jason.mil...@gmail.com>> wrote:
I should not have said anything. Right after I sent this, one of our Mid Tiers 
had corrupt cache and I had to stop TC and delete files. The telltale sign 
usually is that the Work Detail table on the Incident form does not show up. If 
the Work Detail panel is blank we know it is time to do the cache dance with 
that MT server.

Jason

On Wed, Mar 6, 2019 at 9:53 AM Dave Barber 
mailto:daddy.bar...@gmail.com>> wrote:
We have been finding different behaviours across servers; we have 5 or 6 
forms/areas to check, and we can find that each server seems to randomly miss 
elements - doesn't matter if we have made any changes to that form on a 
deployment, the mid tiers just misbehave.  Random selection of 
sync/flush/restart and after an hour or two things tend to be working.

I'll try that method of installation on one of our pre-prod servers, does sound 
very easy.

On Wed, 6 Mar 2019 at 15:12, Jason Miller 
mailto:jason.mil...@gmail.com>> wrote:
We too have issues with 9.1 SP2 and cache. Basically sync cache and flush cache 
features are not usable. Anytime our cache becomes corrupt or a major change 
needs to be picked up, we need to shut down the Mid Tiers and manually delete 
files in ./midtier and ./tomcat. Unfortunately our upgrade to (originally SP4 
but now 18.08) keeps getting delayed for production.

On Wed, Mar 6, 2019 at 7:52 AM Dave Barber 
mailto:daddy.bar...@gmail.com>> wrote:
All,

Our live AR Servers are on 9.1.02. Our mid tiers are on 9.1.03.

There are some really weird caching issues that appear to have been fixed on 
9.1.04 patch 002 - so I have been looking into upgrading the mid tier to 9.1.04 
patch 002. (If anyone is interested, there are massive inconsistencies in the 
mid tier handling of changes - whenever we make a change, we find the mid tiers 
either not reflecting the change, needing several restarts to pick up the 
change, random parts of forms stop rendering properly - CHG:Infrastructure 
Change Work Info table being one that disappears).

9.1.04 itself is fine, but the patching to 9.1.04 patch 002 does not appear to 
work - can't even import the 9.1.04 patch 002 deployment package into the 
deployment console, as it seems to require the 9.1.04 updates to the deployment 
console.

Has anyone manually updated a 9.1.04 mid tier without using the deployment 
management console?

Regards

Dave
--
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist
--
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist
--
ARSList mailing

Group lists and Group Definition

[Mike Galat]

Hi All -

Since upgrading to 18.08 (from 8.1.02) we have seen some strange behavior in a 
couple places.

First, we have a custom people form for our profiles.  On the form, we have two 
display only fields that correspond to the User form fields of Group List (104) 
and Computed Grp List (119).  We have an active link that runs (on Display) if 
the profile is a Support profile (indicating the person should have a 
corresponding User record.)  If so, a set fields is run:

Set Fields: Form User; Qualification: 'Login Name'=$Login ID$; No matches set 
fields to Null, Multiple, Use first matching.  Set:

Computed Grp List <- $Computed Grp List$
Group List from User form <- $Group List$

In 8.1.02 both these group list and computed group list would expand to the 
group names.  In 18.08.00 the behavior I am seeing is the Group List from User 
form will get expanded, while the Computed Group List still just shows numbers:
[cid:image001.png@01D517D4.86FFE300]
Group List from User form: ALL TST TST-GROUP APP-Group-Mgr APP-CM-Shared 
APP-CM-CustApprover
Computed Group List: 61481;61480;21505;75;


For example, the same user has the following group list in the User form:
[cid:image002.png@01D517D4.86FFE300]

Group List: ALL TST TST-GROUP APP-Group-Mgr APP-CM-Shared APP-CM-CustApprover
Computed Group List: APP-Management; APP-Support; AI Arsystem

The next issue I have been seeing is with Computed Group Definition.  Again, we 
have a display only form that allows us to manage groups, for example, create 
groups, inactivate groups, rename groups, etc. which has workflow that goes out 
and updates all the necessary forms when updating groups.  It updates the Group 
form, as well as some custom forms we have, and some other OOTB forms related 
to groups.  We have an active link, that will pull the Group Definition from 
the Group form into a display only field when looking at computed group.  The 
display only field (Computed Group Definition (119)) is a copy of Computed 
Group Definition on Group.  Again, it uses a set fields action:

Set Fields: Form Group; Qualification: 'Group Name' = $Current Group Name$; No 
matches: Display No Match; Multiple Matches: Use first Matching. Set:

Computed Group Definition <- $Computed Group Definition$

In 8.1.02, the definition on our Group updater form will be human readable.  On 
18.08, the field shows up as the internal representation.  For example, from 
18.08:
[cid:image003.png@01D517D4.86FFE300]
Group Definition: 
2\2\4\7\2\4\1\0\2\4\10\%;11;%\4\7\2\4\1\0\2\4\10\%;16;%\4\7\2\4\1\0\2\4\10\%;17;%\

Definition as seen on the Group form:
[cid:image004.png@01D517D4.86FFE300]
Group Definition: "TST-TRAINING2" OR "TST-GROUP" OR "TST-SECURITY"

I took the screen shots from the Remedy User Tool, I do see the same results on 
the midtier.  I added the text of what the fields show, in case ARList does not 
include the screenshots.

Any ideas why this is happening, and how to work around it?

Thanks,
Mike

-- 
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist