Re: Problems with BMC BAO

[Dave Shellman]

Could you tell the group what the issue is?

Dave

On Fri, May 31, 2019 at 5:30 PM Gustavo Tejo  wrote:

> Hello everyone, I have some problems with BMC Atrium Orchestrator, is
> there someone from the group who can help me?
>
> Thanks in advance.
>
>
> Regards
> Gustavo Tejo
>
> --
> 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

Problems with BMC BAO

[Gustavo Tejo]

Hello everyone, I have some problems with BMC Atrium Orchestrator, is there
someone from the group who can help me?

Thanks in advance.


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

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

Re: Mid tier on one, AR Server on another

[Brian Pancia]

We have been running preload in production with a 86400 check interval, chache 
persistence enabled, lifespan enabled, and connection lifespan 15 minutes.  We 
haven't had any major issues with this.  Sometimes if we manually flush the 
cache IE users need to remove their temporary internet files to see the 
changes.  Firefox and Chrome have worked fine.  We're on the latest release.  
However, we've had this configuration since upgrading to 9.x a couple years ago.

Hope that helps.

Brian

From: ARSList  on behalf of Mike Galat 

Sent: Friday, May 31, 2019 8:03 AM
To: ARSList
Subject: RE: Mid tier on one, AR Server on another


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 

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 

ARS Code Deployment Automation

[Dinesh Kumar]

Hi All,

We are in ARS 8.1(no plans for upgrade) and planning to automate the code
deployment, Is there any tool or way that we can completely automate the
deployment process. Please let me know if anyone already done it.

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