Re: Trying to use the AIE to link an item in the CMDB and a person

[Howard Richter]

Roger,

Thanks I was trying just to use OOB, but I am not sure I can.

Thanks,

Howard

On Tue, Jun 24, 2008 at 9:35 PM, Roger Justice <[EMAIL PROTECTED]> wrote:

> ** I had to create new workflow that used the login I could capture in the
> AIE mapping into a new field and then did a filter on Base element to
> capture and push fields to AST:AssetPeople form.
>
>
>
> -Original Message-
> From: Howard Richter <[EMAIL PROTECTED]>
> To: arslist@ARSLIST.ORG
> Sent: Tue, 24 Jun 2008 8:22 pm
> Subject: Trying to use the AIE to link an item in the CMDB and a person
>
>   ** Hi to all,
>
> I have what might be a simple question, but I will ask.
> I have a data exchange create in AIE to move and update data in the
> LANEndpoint and looking to see if there was some way to link the items to a
> persons CI.
> Any ideas welcome.
> Thanks,
>
>
> --
> Howard Richter
> Red Hat Certified Technician
> CompTIA Linux+ Certified
> ITIL Foundation Certified
> E-Mail = [EMAIL PROTECTED]
> LinkedIn Profile = http://www.linkedin.com/in/hbr4270 __Platinum Sponsor:
> www.rmsportal.com ARSlist: "Where the Answers Are" html___
>  --
> Get the Moviefone 
> Toolbar.
> Showtimes, theaters, movie news, & more!
> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> html___




-- 
Howard Richter
Red Hat Certified Technician
CompTIA Linux+ Certified
ITIL Foundation Certified
E-Mail = [EMAIL PROTECTED]
LinkedIn Profile = http://www.linkedin.com/in/hbr4270

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Trying to use the AIE to link an item in the CMDB and a person

[Roger Justice]

I had to create new workflow that used the login I could capture in the AIE 
mapping into a new field and then did a filter on Base element to capture and 
push fields to AST:AssetPeople form.


-Original Message-
From: Howard Richter <[EMAIL PROTECTED]>
To: arslist@ARSLIST.ORG
Sent: Tue, 24 Jun 2008 8:22 pm
Subject: Trying to use the AIE to link an item in the CMDB and a person


** 
Hi to all,

?

I have what might be a simple question, but I will ask.

I have a data exchange create in AIE to move and update data in the LANEndpoint 
and looking to see if there was some way to link the items to a persons CI. 

Any ideas welcome.

Thanks,


-- 
Howard Richter
Red Hat Certified Technician
CompTIA Linux+ Certified
ITIL Foundation Certified 
E-Mail = [EMAIL PROTECTED]
LinkedIn Profile = http://www.linkedin.com/in/hbr4270 __Platinum Sponsor: 
www.rmsportal.com ARSlist: "Where the Answers Are" html___ 

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Trying to use the AIE to link an item in the CMDB and a person

[Howard Richter]

Hi to all,

I have what might be a simple question, but I will ask.

I have a data exchange create in AIE to move and update data in the
LANEndpoint and looking to see if there was some way to link the items to a
persons CI.

Any ideas welcome.

Thanks,


-- 
Howard Richter
Red Hat Certified Technician
CompTIA Linux+ Certified
ITIL Foundation Certified
E-Mail = [EMAIL PROTECTED]
LinkedIn Profile = http://www.linkedin.com/in/hbr4270

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Integrating with another company's ARSystem

[Carey Matthew Black]

Shawn,

 The only "advantage" that I can think of for "DSO over Web
Services" is that ARS DSO is designed to deal with the case of "the
other side is down right now... try again later" while ARS Web
Services is only designed to be a real time process. So if the other
side is down, then the working side will see errors and could prevent
normal functionality if the integration is designed in a very simple
manor. However if the Web Services integration is done in a more
"non-trivial" way, then that functionality can also be achieved. It
just takes more than a single set field action to get the job done. (
Like involving a queue form[interface] and maybe an external process
to keep moving the data back and forth. Not a trivial task for most
shops to do. )

-- 
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)

Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap Pick two.



On Tue, Jun 24, 2008 at 2:22 PM, Pierson, Shawn <[EMAIL PROTECTED]> wrote:
> **
>
> You know, the same thing applies to web services, and I'm not aware of any
> advantages of DSO over web services at this time if you're building an
> integration form that is used on both sides, with workflow to push to each
> separately.
>
>
>
> Shawn Pierson
>
>
>
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] On Behalf Of Nall, Roger
> Sent: Tuesday, June 24, 2008 1:08 PM
> To: arslist@ARSLIST.ORG
> Subject: Re: Integrating with another company's ARSystem
>
>
>
> **
>
> John,
>
>
>
> It is much easier to create a DSO form for each integration point. This form
> would become part of both systems. Changes should only be made to this form
> on both sides. You would then push data from your main form to the DSO form
> to the other DSO form where the other system would push the data to their
> main form. There are special DSO fields that will let you know when
> transfers succeed or fail. If you look at the DSO configuration book that
> will give you an idea.
>
>
>
> HTH,
>
>
>
> Roger A. Nall
> Manager, OSSNMS Remedy
> T-Mobile, USA
> Desk: 813-348-2556
> Cell: 973-652-6723
> FAX: 813-348-2565
> sf49fanv AIM IM
> RogerNall Yahoo IM
>
> 
>
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] On Behalf Of Reiser, John J
> Sent: Tuesday, June 24, 2008 1:53 PM
> To: arslist@ARSLIST.ORG
> Subject: Re: Integrating with another company's ARSystem
>
>
>
> Roger, Rick and Robert,
>
>
>
> Thanks for the replies.
>
> Yes it is vague.
>
> Yes it will be a challenge.
>
> Especially since the other system is a US Navy system and I am sure security
> will be tight.
>
>
>
> Right now this is "pie-in-the-sky" but that never stopped them before;^>
>
>
>
>
>
> Robert, I have a question about your DSO statement. I thought the idea
> behind DSO was also to allow you to connect to a different form structure
> and still pass relevant data.
>
> We are purchasing DSO for another project and they use ITSM, we use our home
> grown Helpdesk. We just need to pass Ticket ID's as reference data as well
> as problem summary and user info. This was suggested to us by the Developers
> on the ITSM site.
>
>
>
> Thanks,
>
> John J. Reiser
> Software Development Analyst
> Remedy Administrator/Developer
> Lockheed Martin - MS2
> The star that burns twice as bright burns half as long.
> Pay close attention and be illuminated by its brilliance. - paraphrased by
> me
>
>
>
>
>
> 
>
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook
> Sent: Tuesday, June 24, 2008 11:31 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: Integrating with another company's ARSystem
>
> ** Excellent point about DSO.  I think the key here is being able to
> establish either a secure gateway between the two AR servers or a common
> middle ground (which means server, forms, etc.).  Since you have zero
> dollars to spend on hardware, it looks like you should be investigating how
> to tunnel from one AR server to the other in some way, like Robert said,
> using some common data forms, assuming that the data is common enough to
> make that possible.  Do you know anything about the other AR System and it's
> applications?  If not, now would be a great time to start finding out, so
> that you have the answers before anyone asks more questions and defines
> unrealistic expectations for you.
>
> Or, you could bypass AR System altogether, and create SQL views into the
> DBs, and view them from a web page or something.  Like I said, until you are
> given a better definition of what they want, it's really premature to design
> the solution for it.
>
> From a business perspective, there are two tacks you can take:
> 1)  Tell them that "Yes, it's probably possible", then toss it back to them
> for a better definition of what they want.
> 2)  Define the rules yourself by telling them the mean

Kforce / Permanent / McLean - VA / Remedy Developer - Will Relocate

[Kitchen, Joshua T]

Dear List,

 

Hope all is well, Kforce is looking for a talented Remedy Developer
local or willing to relocate to the Virginia area for a permanent
position with one of our clients.  

 

Title:  Remedy Developer

Type:  Direct-Hire at Client

Authorization Status:  US Citizen/Green Card/EAD/H1-B Visa

Duration:  Permanent

Salary:  75,000-90,000 + 12% Bonus (Full Relocation Offered)

Location:  McLean, VA

Interview Process:  1st round phone, 2nd round in-person (We will fly
you in for interview)

 

Industry:

 

Our client is a stockholder - owned corporation chartered by Congress to
increase the supply of funds that mortgage lenders, such as commercial
banks, mortgage bankers, savings institutions and credit unions, can
make available to homebuyers and multifamily investors. 

 

Since 1970, our client has pursued the purpose their Congressional
founders set out for them: to provide a continuous and low - cost source
of credit to finance America's housing. They achieve this purpose by 

 

1)  Making mortgage funds available whenever and wherever Americans need
them by linking the worldwide capital markets to the U.S. mortgage
markets 

2)  Providing a continuous, reliable and low - cost flow of mortgage
capital to finance housing for the nation's homebuyers and renters 

3)  Bringing the benefits of the market in which we operate - the
secondary mortgage market - to families and communities across the
nation 

4)  Their business is primarily by buying mortgages from lenders,
packaging the mortgages into securities and selling the securities -
guaranteed by Freddie Mac - to investors. 5)  Mortgage lenders use the
proceeds from selling loans to Freddie Mac to fund new mortgages,
constantly replenishing the pool of funds available for lending to
homebuyers and apartment owners. Just as stock and bond markets have put
investor capital to work for corporations, the secondary mortgage market
puts private investor capital to work for homebuyers and apartment
owners, providing a continuous flow of affordable funds for home
financing. 

 

For the most part, the process is invisible to borrowers and renters.
But because our client exists, millions of Americans have benefited from
lower monthly mortgage payments and better access to home financing. In
fact, for more than 35 years they have opened doors for one in six
homebuyers and more than four million renters in America.

 

Job Responsibilities: 

Performs analysis, design, and development, of Remedy v. 7.1 Service
Desk.  Analyze requirements and create design specifications to meet the
project needs. Perform customization/workflow as determined. Develop new
workflows, active links, forms, and escalations in the Remedy suite.
Builds and executes unit test cases, as wells documents developer
guides, training guides, user guides and support guides.  Provide
support and Sustainment to the Remedy applications.  Researches and
recommends technologies to improve Remedy applications. 

Basic Qualifications: 
* 3-5 years of Remedy development experience in 6.3 and 7.x.



Plus Qualifications

* Experience in developing in Crystal Reports. 

* Experience in Remedy Migrator 

* Experience with CMDB. 

* Integration of REMEDY with external systems using REMEDY APIs, web
services, REMEDY Import etc. 
* Experience with Rational Clear Case for software configuration
management and Rational Clear Quest for Change Defect Management 

 

Respectfully,

 
Joshua Kitchen
Information Technology Recruiter
Kforce Professional Staffing 
Two Prestige Place (Suite 350)
937.449.1749 Office  
937.461.6888 Fax 
937.416.3456 Cell
Great People = Great Results
   
Please don't keep me a secret... a referral is the best compliment I can
receive. 
 

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
<>

Job: Remedy Developer - Oklahoma City - Contract to Hire - Kforce

[Kitchen, Joshua T]

Hope all is well, Kforce is looking for a talented Remedy Developer
local or willing to relocate to the Oklahoma City, Oklahoma for a 6
month contract to hire with one of our top clients.

 

Title:  Remedy Developer

Type:  6 Month Contract-to-Hire

Authorization Status:  US Citizen/Green Card/EAD/H1-B Visa

Duration:  6 Months then must be willing to go perm

Location:  Oklahoma City, Oklahoma

Interview Process:  1st round phone, 2nd round in-person 

 

Industry:

 

Our client is a leading provider of C4ISR, Homeland Security,
Intelligence, Enterprise IT and Aerospace services and solutions to the
U.S. Department of Defense, the intelligence community and other federal
civilian government agencies. With deep and long-standing customer
relationships, our client has 10,000 employees working on over 2,000
contracts. Over 8,000 of our clients personnel have security clearances.


 

Job Responsibilities: 

Performs analysis, design, and development, of Remedy v. 7.1 Service
Desk.  Analyze requirements and create design specifications to meet the
project needs. Perform customization/workflow as determined. Develop new
workflows, active links, forms, and escalations in the Remedy suite.
Builds and executes unit test cases, as wells documents developer
guides, training guides, user guides and support guides.  Provide
support and Sustainment to the Remedy applications.  Researches and
recommends technologies to improve Remedy applications. 

Basic Qualifications: 
* 3-5 years of Remedy development experience in 6.3 and 7.x.



Plus Qualifications

* Experience in developing in Crystal Reports. 

* Integration of REMEDY with external systems using REMEDY APIs, web
services, REMEDY Import etc. 
* Experience with Rational Clear Case for software configuration
management and Rational Clear Quest for Change Defect Management 

 
Education:

Bachelors degree in computer science, information systems, engineering
or other related discipline is required. 
 
Respectfully,

Joshua Kitchen
Information Technology Recruiter
Kforce Professional Staffing 
Two Prestige Place (Suite 350)
937.449.1749 Office  
937.461.6888 Fax 
937.416.3456 Cell
Great People = Great Results
   
Please don't keep me a secret... a referral is the best compliment I can
receive. 

 

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
<>

Re: Integrating with another company's ARSystem

[Reiser, John J]

My fault for straying from the subject line. Thanks for answers to both
of my questions.
Since "they" are the corporate Helpdesk using ITSM we will change to
accommodate the field requirements.
I will be working with a developer to get this off the ground. I hope to
get this in place inside our structure and then use the knowledge to
guide us in the connection to the "other" company site.
 
Thanks,
 

John J. Reiser
Software Development Analyst
Remedy Administrator/Developer
Lockheed Martin - MS2
The star that burns twice as bright burns half as long.
Pay close attention and be illuminated by its brilliance. - paraphrased
by me



 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Pierson, Shawn
Sent: Tuesday, June 24, 2008 2:23 PM
To: arslist@ARSLIST.ORG
Subject: Re: Integrating with another company's ARSystem


** 

You know, the same thing applies to web services, and I'm not aware of
any advantages of DSO over web services at this time if you're building
an integration form that is used on both sides, with workflow to push to
each separately.

 

Shawn Pierson

 

From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Nall, Roger
Sent: Tuesday, June 24, 2008 1:08 PM
To: arslist@ARSLIST.ORG
Subject: Re: Integrating with another company's ARSystem

 

** 

John,

 

It is much easier to create a DSO form for each integration point. This
form would become part of both systems. Changes should only be made to
this form on both sides. You would then push data from your main form to
the DSO form to the other DSO form where the other system would push the
data to their main form. There are special DSO fields that will let you
know when transfers succeed or fail. If you look at the DSO
configuration book that will give you an idea.

 

HTH,

 

Roger A. Nall 
Manager, OSSNMS Remedy 
T-Mobile, USA 
Desk: 813-348-2556 
Cell: 973-652-6723 
FAX: 813-348-2565 
sf49fanv AIM IM 
RogerNall Yahoo IM 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Reiser, John J
Sent: Tuesday, June 24, 2008 1:53 PM
To: arslist@ARSLIST.ORG
Subject: Re: Integrating with another company's ARSystem

 

Roger, Rick and Robert,

 

Thanks for the replies.

Yes it is vague.

Yes it will be a challenge.

Especially since the other system is a US Navy system and I am sure
security will be tight.

 

Right now this is "pie-in-the-sky" but that never stopped them before;^>

 

 

Robert, I have a question about your DSO statement. I thought the idea
behind DSO was also to allow you to connect to a different form
structure and still pass relevant data.

We are purchasing DSO for another project and they use ITSM, we use our
home grown Helpdesk. We just need to pass Ticket ID's as reference data
as well as problem summary and user info. This was suggested to us by
the Developers on the ITSM site.

 

Thanks,

John J. Reiser
Software Development Analyst
Remedy Administrator/Developer
Lockheed Martin - MS2
The star that burns twice as bright burns half as long.
Pay close attention and be illuminated by its brilliance. - paraphrased
by me

 

 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook
Sent: Tuesday, June 24, 2008 11:31 AM
To: arslist@ARSLIST.ORG
Subject: Re: Integrating with another company's ARSystem

** Excellent point about DSO.  I think the key here is being able to
establish either a secure gateway between the two AR servers or a common
middle ground (which means server, forms, etc.).  Since you have zero
dollars to spend on hardware, it looks like you should be investigating
how to tunnel from one AR server to the other in some way, like Robert
said, using some common data forms, assuming that the data is common
enough to make that possible.  Do you know anything about the other AR
System and it's applications?  If not, now would be a great time to
start finding out, so that you have the answers before anyone asks more
questions and defines unrealistic expectations for you.

Or, you could bypass AR System altogether, and create SQL views into the
DBs, and view them from a web page or something.  Like I said, until you
are given a better definition of what they want, it's really premature
to design the solution for it.

>From a business perspective, there are two tacks you can take:
1)  Tell them that "Yes, it's probably possible", then toss it back to
them for a better definition of what they want.
2)  Define the rules yourself by telling them the means by which this
can most likely be done, and then ask them to fit what they want into
that.

Rick

On Tue, Jun 24, 2008 at 8:11 AM, Robert Molenda
<[EMAIL PROTECTED]> wrote:

** 

I agree with Rick... Could be easy - could be next to impossible...

 

DSO is OK provided that the systems are configured the same - sa

Kforce / Contract to Hire / Portland, Oregon / Remedy Administrator

[Kitchen, Joshua T]

Dear List,

 

Hope all is well, Kforce is looking for a talented Remedy Administrator.


 

Title:  Remedy  ARS Administrator 

 

Type:Contract to Hire 

 

Authorization Status:  US Citizen 

 

Duration:  3 Month contract to hire   

 

Location:   Portland, Oregon 


Interview Process:  1st round phone, 2nd round in-person (We will fly
you in for interview)

 

Job Responsibilities:  

*   Remedy ARS software development.  Responsible for research and
evaluation of new products, license management, administration, and
performance tuning. 
*   
Configuration an ARS System to include identification and
solution of production problems, system and data cleanup and maintenance
tasks, workflow and user account management, providing user assistance
and performing system fail over, backup, and recovery.
*   
Provide complete and easy-to-understand documentation and
training for all phases of development including requirements analysis,
design, and technical and user instructional documentation.
*   
Design and make enhancements to existing ARS System.
*   
Gather and document customer requirements, design solutions,
document specifications, develop software applications, test
applications, and implement. 
*   
Provide technical assistance and advice as requested. Provide
technical recommendations and training to team members.
*   
Provide technical support to remote administrators and users.
Create products, techniques and procedures to enhance the efficiency of
the customer support process. 

Basic Qualifications:  

*1 years of Remedy development experience in 6.3 or 7.x. 

 Educational Requirements

*   Bachelor's degree in Engineering or Science 

 If you are interested please send me an email to [EMAIL PROTECTED]
  with your resume and salary requirements.

 

 Respectfully,

 
Joshua Kitchen
Information Technology Recruiter
Kforce Professional Staffing 
Two Prestige Place (Suite 350)
937.449.1749 Office  
937.461.6888 Fax 
937.416.3456 Cell
Great People = Great Results
   
Please don't keep me a secret... a referral is the best compliment I can
receive. 
 

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
<>

Re: Integrating with another company's ARSystem

[Jason Miller]

Hi John,

So you are looking to integrate a server at a corporate location (non DoD)
to the Navy's network?  That is most likely going to really limit your
options.  Any connections that you are going to make will have to be on a
Navy approved port (unless you can get an exception or use a VPN).  Web
services may very well be a good option 1) because it is built into Remedy
and 2) it can run on port 443 which is an approved port.  ARSXML will also
run on port 443 and is similar to DSO (some would say better than DSO)
however with your budgetary limits this probably isn't an option (Navy
pricing was 10-13k if I remember right).

Do you know if the Navy system you wanting to connect to is part of the
Shared Data Environment (SDE)?  If so they will already have a form setup
with the common data elements and already be using DSO or ARSXML with other
ARS servers in the Navy.  I was working on a project where we implemented
ITSM 6 for the Navy and integrated with DSO to their custom built Help Desk
form on another server.  Both systems had a copy of the DSO form and then we
used DSO to keep our Help Desk forms synchronized with that form on the same
server (this way field 1 kept the prefix for the site where it originated).
Instead of completely reworking the ITSM Help Desk form to meet the Navy's
specs (upgrade nightmare), we created fields on the Help Desk that received
the DSO data and then filters that would correctly translate that data in to
OOB Help Desk data (ex. priorities were reversed, custom Navy Status values
to ITSM status, etc.).

HTH,
Jason


On Tue, Jun 24, 2008 at 10:53 AM, Reiser, John J <[EMAIL PROTECTED]>
wrote:

> ** Roger, Rick and Robert,
>
> Thanks for the replies.
> Yes it is vague.
> Yes it will be a challenge.
> Especially since the other system is a US Navy system and I am sure
> security will be tight.
>
> Right now this is "pie-in-the-sky" but that never stopped them before;^>
>
>
> Robert, I have a question about your DSO statement. I thought the idea
> behind DSO was also to allow you to connect to a different form structure
> and still pass relevant data.
> We are purchasing DSO for another project and they use ITSM, we use our
> home grown Helpdesk. We just need to pass Ticket ID's as reference data as
> well as problem summary and user info. This was suggested to us by the
> Developers on the ITSM site.
>
> Thanks,
>
> John J. Reiser
> Software Development Analyst
> Remedy Administrator/Developer
> Lockheed Martin - MS2
> The star that burns twice as bright burns half as long.
> Pay close attention and be illuminated by its brilliance. - paraphrased by
> me
>
>
>
>  --
> *From:* Action Request System discussion list(ARSList) [mailto:
> [EMAIL PROTECTED] *On Behalf Of *Rick Cook
> *Sent:* Tuesday, June 24, 2008 11:31 AM
> *To:* arslist@ARSLIST.ORG
> *Subject:* Re: Integrating with another company's ARSystem
>
> ** Excellent point about DSO.  I think the key here is being able to
> establish either a secure gateway between the two AR servers or a common
> middle ground (which means server, forms, etc.).  Since you have zero
> dollars to spend on hardware, it looks like you should be investigating how
> to tunnel from one AR server to the other in some way, like Robert said,
> using some common data forms, assuming that the data is common enough to
> make that possible.  Do you know anything about the other AR System and it's
> applications?  If not, now would be a great time to start finding out, so
> that you have the answers before anyone asks more questions and defines
> unrealistic expectations for you.
>
> Or, you could bypass AR System altogether, and create SQL views into the
> DBs, and view them from a web page or something.  Like I said, until you are
> given a better definition of what they want, it's really premature to design
> the solution for it.
>
> From a business perspective, there are two tacks you can take:
> 1)  Tell them that "Yes, it's probably possible", then toss it back to them
> for a better definition of what they want.
> 2)  Define the rules yourself by telling them the means by which this can
> most likely be done, and then ask them to fit what they want into that.
>
> Rick
>
> On Tue, Jun 24, 2008 at 8:11 AM, Robert Molenda <[EMAIL PROTECTED]>
> wrote:
>
>> ** I agree with Rick... Could be easy - could be next to impossible...
>>
>> DSO is OK provided that the systems are configured the same - same fields
>> - same configuration data - same-same...
>>
>> Web Services is probably the best method to do "Ticket Passing" which is
>> what I have to assume you are referring to between the two companies. Works
>> fine over a secure vpn tunnel as well. Only issue is host-name-resolution...
>>
>> You must create a common "interface" that will be used on 'both sides' to
>> send / receive the data and then custom workflow on each end to 'store the
>> data' in the appropriate form + format + field definitions.
>>
>> More 'details' wo

Re: Nav Fields and workflow

[Gary Dries]

Resolved, it needed to fire on Display, plus the data that was being
provided had special characters in it so I altered the Run if to a LIKE
statement.

Thanks for the quick response and snap starting my brain.

Gary Dries

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Nav Fields and workflow

[Grooms, Frederick W]

Except for forms being Opened in a Dialog, Window Open fires before data
is loaded in the form (and data used in Window Open is cleared before
Display).
You should use Window Loaded or Display.
 
Fred



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Gary Dries
Sent: Tuesday, June 24, 2008 2:18 PM
To: arslist@ARSLIST.ORG
Subject: Nav Fields and workflow


** All
I am running into a quirk with Navigation Items in a Vertical/Horizontal
Nav field.  
This is 7.0.01 Patch 4 running a SQL 2000 db on Server 2000. WUT 7.0.01
custom App

I have created a Nav field with several Nav Menus and each menu has 2 to
6 Nav Items.  In this case I have set the Nav Item to be disabled by
default.  I then create a very basic Active link to make the Nav Item
enabled.
The A.L. runs on Window Open, the Run If is 'field name' = "value"
Change Field Action on said Nav Item, Field Access Enabled.

When I open the form and the field name' = "value" the logs say the A.L.
does not qualify, but if I make the Run If NULL, then it qualifies, if I
make the Run If 1=1 then it qualifies, but  'field name' = "value" does
not.  I have even used 'Request ID' = "TT00100" and opened that
record, still nothing.

I have searched the KBs and ARSList entries but have found nothing
related to this any ideas?

-- 
Gary Dries
T-Mobile USA

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___ 

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Nav Fields and workflow

[Gary Dries]

I have tried on Display, Window, Open and Window Loaded, same results.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Nav Fields and workflow

[LJ Longwing]

If I remember correctly, Window Open happens before the data is loaded in
the form, try changing it to 'Window Loaded' with your field qual and I
think you will see that it happens properly then

  _  

From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Gary Dries
Sent: Tuesday, June 24, 2008 1:18 PM
To: arslist@ARSLIST.ORG
Subject: Nav Fields and workflow


** All
I am running into a quirk with Navigation Items in a Vertical/Horizontal Nav
field.  
This is 7.0.01 Patch 4 running a SQL 2000 db on Server 2000. WUT 7.0.01
custom App

I have created a Nav field with several Nav Menus and each menu has 2 to 6
Nav Items.  In this case I have set the Nav Item to be disabled by default.
I then create a very basic Active link to make the Nav Item enabled.
The A.L. runs on Window Open, the Run If is 'field name' = "value" Change
Field Action on said Nav Item, Field Access Enabled.

When I open the form and the field name' = "value" the logs say the A.L.
does not qualify, but if I make the Run If NULL, then it qualifies, if I
make the Run If 1=1 then it qualifies, but  'field name' = "value" does not.
I have even used 'Request ID' = "TT00100" and opened that record,
still nothing.

I have searched the KBs and ARSList entries but have found nothing related
to this any ideas?

-- 
Gary Dries
T-Mobile USA

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___ 

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Nav Fields and workflow

[Tanner, Doug]

Try it on Window Loaded

 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Gary Dries
Sent: Tuesday, June 24, 2008 3:18 PM
To: arslist@ARSLIST.ORG
Subject: Nav Fields and workflow

 

** All
I am running into a quirk with Navigation Items in a Vertical/Horizontal
Nav field.  
This is 7.0.01 Patch 4 running a SQL 2000 db on Server 2000. WUT 7.0.01
custom App

I have created a Nav field with several Nav Menus and each menu has 2 to
6 Nav Items.  In this case I have set the Nav Item to be disabled by
default.  I then create a very basic Active link to make the Nav Item
enabled.
The A.L. runs on Window Open, the Run If is 'field name' = "value"
Change Field Action on said Nav Item, Field Access Enabled.

When I open the form and the field name' = "value" the logs say the A.L.
does not qualify, but if I make the Run If NULL, then it qualifies, if I
make the Run If 1=1 then it qualifies, but  'field name' = "value" does
not.  I have even used 'Request ID' = "TT00100" and opened that
record, still nothing.

I have searched the KBs and ARSList entries but have found nothing
related to this any ideas?

-- 
Gary Dries
T-Mobile USA

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___ 


DISCLAIMER Important! This message is intended for the above named person(s) 
only and is CONFIDENTIAL AND PROPRIETARY. If you are not the intended recipient 
of this e-mail and have received it in error, please immediately notify the 
sender by return email and then delete it from your mailbox. This message may 
be protected by the attorney-client privilege and/or work product doctrine.  
Accessing, copying, disseminating or re-using any of the information contained 
in this e-mail by anyone other than the intended recipient is strictly 
prohibited. Finally, you should check this email and any attachments for the 
presence of viruses, as the sender accepts no liability for any damage caused 
by any virus transmitted by this email.  Thank you.


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Nav Fields and workflow

[Gary Dries]

All
I am running into a quirk with Navigation Items in a Vertical/Horizontal Nav
field.
This is 7.0.01 Patch 4 running a SQL 2000 db on Server 2000. WUT 7.0.01
custom App

I have created a Nav field with several Nav Menus and each menu has 2 to 6
Nav Items.  In this case I have set the Nav Item to be disabled by default.
I then create a very basic Active link to make the Nav Item enabled.
The A.L. runs on Window Open, the Run If is '*field name' = "value" *Change
Field Action on said Nav Item, Field Access Enabled.

When I open the form and the *field name' = "value" *the logs say the A.L.
does not qualify, but if I make the Run If NULL, then it qualifies, if I
make the Run If 1=1 then it qualifies, but  *'field name' = "value" *does
not.  I have even used 'Request ID' = "TT00100" and opened that
record, still nothing.

I have searched the KBs and ARSList entries but have found nothing related
to this any ideas?

-- 
Gary Dries
T-Mobile USA

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

ITIL or Best Practice Pending Status Guidelines

[Koyb P. Liabt]

Hi,

Are there any best practice/ITIL white papers or guidelines for Pending 
tickets’ time limit?  Right now our Help Desk tickets are in the pending status 
for 2 weeks.  I have been searching the internet with no success finding this.  
I would be interested in knowing how other company's are determining how long 
tickets can remain in a Pending status.




___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Integrating with another company's ARSystem

[Pierson, Shawn]

You know, the same thing applies to web services, and I'm not aware of
any advantages of DSO over web services at this time if you're building
an integration form that is used on both sides, with workflow to push to
each separately.



Shawn Pierson



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Nall, Roger
Sent: Tuesday, June 24, 2008 1:08 PM
To: arslist@ARSLIST.ORG
Subject: Re: Integrating with another company's ARSystem



**

John,



It is much easier to create a DSO form for each integration point. This
form would become part of both systems. Changes should only be made to
this form on both sides. You would then push data from your main form to
the DSO form to the other DSO form where the other system would push the
data to their main form. There are special DSO fields that will let you
know when transfers succeed or fail. If you look at the DSO
configuration book that will give you an idea.



HTH,



Roger A. Nall
Manager, OSSNMS Remedy
T-Mobile, USA
Desk: 813-348-2556
Cell: 973-652-6723
FAX: 813-348-2565
sf49fanv AIM IM
RogerNall Yahoo IM



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Reiser, John J
Sent: Tuesday, June 24, 2008 1:53 PM
To: arslist@ARSLIST.ORG
Subject: Re: Integrating with another company's ARSystem



Roger, Rick and Robert,



Thanks for the replies.

Yes it is vague.

Yes it will be a challenge.

Especially since the other system is a US Navy system and I am sure
security will be tight.



Right now this is "pie-in-the-sky" but that never stopped them before;^>





Robert, I have a question about your DSO statement. I thought the idea
behind DSO was also to allow you to connect to a different form
structure and still pass relevant data.

We are purchasing DSO for another project and they use ITSM, we use our
home grown Helpdesk. We just need to pass Ticket ID's as reference data
as well as problem summary and user info. This was suggested to us by
the Developers on the ITSM site.



Thanks,

John J. Reiser
Software Development Analyst
Remedy Administrator/Developer
Lockheed Martin - MS2
The star that burns twice as bright burns half as long.
Pay close attention and be illuminated by its brilliance. - paraphrased
by me







From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook
Sent: Tuesday, June 24, 2008 11:31 AM
To: arslist@ARSLIST.ORG
Subject: Re: Integrating with another company's ARSystem

** Excellent point about DSO.  I think the key here is being able to
establish either a secure gateway between the two AR servers or a common
middle ground (which means server, forms, etc.).  Since you have zero
dollars to spend on hardware, it looks like you should be investigating
how to tunnel from one AR server to the other in some way, like Robert
said, using some common data forms, assuming that the data is common
enough to make that possible.  Do you know anything about the other AR
System and it's applications?  If not, now would be a great time to
start finding out, so that you have the answers before anyone asks more
questions and defines unrealistic expectations for you.

Or, you could bypass AR System altogether, and create SQL views into the
DBs, and view them from a web page or something.  Like I said, until you
are given a better definition of what they want, it's really premature
to design the solution for it.

>From a business perspective, there are two tacks you can take:
1)  Tell them that "Yes, it's probably possible", then toss it back to
them for a better definition of what they want.
2)  Define the rules yourself by telling them the means by which this
can most likely be done, and then ask them to fit what they want into
that.

Rick

On Tue, Jun 24, 2008 at 8:11 AM, Robert Molenda
<[EMAIL PROTECTED]> wrote:

**

I agree with Rick... Could be easy - could be next to impossible...



DSO is OK provided that the systems are configured the same - same
fields - same configuration data - same-same...



Web Services is probably the best method to do "Ticket Passing" which is
what I have to assume you are referring to between the two companies.
Works fine over a secure vpn tunnel as well. Only issue is
host-name-resolution...



You must create a common "interface" that will be used on 'both sides'
to send / receive the data and then custom workflow on each end to
'store the data' in the appropriate form + format + field definitions.



More 'details' would be helpful - you could actually get away with not
even transfering the tickets - however using web-services to create a
remote view into the other system, etc. All depends upon the
requirements.



HTH



Robert Molenda

On Tue, Jun 24, 2008 at 7:50 AM, Rick Cook <[EMAIL PROTECTED]> wrote:

** John, "integration" is, as you said, pretty vague.  Perhaps once you
have a better idea of its scale and definition, we mi

Re: Integrating with another company's ARSystem

[Shellman, David]

John,
 
I think the big issue with DSO is that it's a batch process and you need
to create maps from one system to the other.  If the systems are not
near identical then issues can crop up because of differences in field
lengths, different values for Status field, etc.  Not to say it can't be
done but it maybe painful.  
 
Dave


From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Reiser, John J
Sent: Tuesday, June 24, 2008 1:53 PM
To: arslist@ARSLIST.ORG
Subject: Re: Integrating with another company's ARSystem


** 
Roger, Rick and Robert,
 
Thanks for the replies.
Yes it is vague.
Yes it will be a challenge.
Especially since the other system is a US Navy system and I am sure
security will be tight.
 
Right now this is "pie-in-the-sky" but that never stopped them before;^>
 
 
Robert, I have a question about your DSO statement. I thought the idea
behind DSO was also to allow you to connect to a different form
structure and still pass relevant data.
We are purchasing DSO for another project and they use ITSM, we use our
home grown Helpdesk. We just need to pass Ticket ID's as reference data
as well as problem summary and user info. This was suggested to us by
the Developers on the ITSM site.
 
Thanks,

John J. Reiser
Software Development Analyst
Remedy Administrator/Developer
Lockheed Martin - MS2
The star that burns twice as bright burns half as long.
Pay close attention and be illuminated by its brilliance. - paraphrased
by me



 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook
Sent: Tuesday, June 24, 2008 11:31 AM
To: arslist@ARSLIST.ORG
Subject: Re: Integrating with another company's ARSystem


** Excellent point about DSO.  I think the key here is being able to
establish either a secure gateway between the two AR servers or a common
middle ground (which means server, forms, etc.).  Since you have zero
dollars to spend on hardware, it looks like you should be investigating
how to tunnel from one AR server to the other in some way, like Robert
said, using some common data forms, assuming that the data is common
enough to make that possible.  Do you know anything about the other AR
System and it's applications?  If not, now would be a great time to
start finding out, so that you have the answers before anyone asks more
questions and defines unrealistic expectations for you.

Or, you could bypass AR System altogether, and create SQL views into the
DBs, and view them from a web page or something.  Like I said, until you
are given a better definition of what they want, it's really premature
to design the solution for it.

>From a business perspective, there are two tacks you can take:
1)  Tell them that "Yes, it's probably possible", then toss it back to
them for a better definition of what they want.
2)  Define the rules yourself by telling them the means by which this
can most likely be done, and then ask them to fit what they want into
that.

Rick


On Tue, Jun 24, 2008 at 8:11 AM, Robert Molenda
<[EMAIL PROTECTED]> wrote:


** 
I agree with Rick... Could be easy - could be next to
impossible...
 
DSO is OK provided that the systems are configured the same -
same fields - same configuration data - same-same...
 
Web Services is probably the best method to do "Ticket Passing"
which is what I have to assume you are referring to between the two
companies. Works fine over a secure vpn tunnel as well. Only issue is
host-name-resolution...
 
You must create a common "interface" that will be used on 'both
sides' to send / receive the data and then custom workflow on each end
to 'store the data' in the appropriate form + format + field
definitions.
 
More 'details' would be helpful - you could actually get away
with not even transfering the tickets - however using web-services to
create a remote view into the other system, etc. All depends upon the
requirements.
 
HTH
 
Robert Molenda


On Tue, Jun 24, 2008 at 7:50 AM, Rick Cook
<[EMAIL PROTECTED]> wrote:


** John, "integration" is, as you said, pretty vague.
Perhaps once you have a better idea of its scale and definition, we
might be able to give better answers.  Could be anything from very
simple to you-gotta-be-kidding. 


Rick 


On Tue, Jun 24, 2008 at 7:40 AM, Reiser, John J
<[EMAIL PROTECTED]> wrote:


Hello Listers,

Current configuration
ARS 6.3 Patch 014
Midtier 6.3 Patch 021
MS SQL Server 2000

Upgrade path
ARS 7.1
Midtier 7
MS 

Re: Integrating with another company's ARSystem

[Nall, Roger]

John,

 

It is much easier to create a DSO form for each integration point. This
form would become part of both systems. Changes should only be made to
this form on both sides. You would then push data from your main form to
the DSO form to the other DSO form where the other system would push the
data to their main form. There are special DSO fields that will let you
know when transfers succeed or fail. If you look at the DSO
configuration book that will give you an idea.

 

HTH,

 

Roger A. Nall 
Manager, OSSNMS Remedy 
T-Mobile, USA 
Desk: 813-348-2556 
Cell: 973-652-6723 
FAX: 813-348-2565 
sf49fanv AIM IM 
RogerNall Yahoo IM 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Reiser, John J
Sent: Tuesday, June 24, 2008 1:53 PM
To: arslist@ARSLIST.ORG
Subject: Re: Integrating with another company's ARSystem

 

Roger, Rick and Robert,

 

Thanks for the replies.

Yes it is vague.

Yes it will be a challenge.

Especially since the other system is a US Navy system and I am sure
security will be tight.

 

Right now this is "pie-in-the-sky" but that never stopped them before;^>

 

 

Robert, I have a question about your DSO statement. I thought the idea
behind DSO was also to allow you to connect to a different form
structure and still pass relevant data.

We are purchasing DSO for another project and they use ITSM, we use our
home grown Helpdesk. We just need to pass Ticket ID's as reference data
as well as problem summary and user info. This was suggested to us by
the Developers on the ITSM site.

 

Thanks,

John J. Reiser
Software Development Analyst
Remedy Administrator/Developer
Lockheed Martin - MS2
The star that burns twice as bright burns half as long.
Pay close attention and be illuminated by its brilliance. - paraphrased
by me

 

 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook
Sent: Tuesday, June 24, 2008 11:31 AM
To: arslist@ARSLIST.ORG
Subject: Re: Integrating with another company's ARSystem

** Excellent point about DSO.  I think the key here is being able to
establish either a secure gateway between the two AR servers or a common
middle ground (which means server, forms, etc.).  Since you have zero
dollars to spend on hardware, it looks like you should be investigating
how to tunnel from one AR server to the other in some way, like Robert
said, using some common data forms, assuming that the data is common
enough to make that possible.  Do you know anything about the other AR
System and it's applications?  If not, now would be a great time to
start finding out, so that you have the answers before anyone asks more
questions and defines unrealistic expectations for you.

Or, you could bypass AR System altogether, and create SQL views into the
DBs, and view them from a web page or something.  Like I said, until you
are given a better definition of what they want, it's really premature
to design the solution for it.

>From a business perspective, there are two tacks you can take:
1)  Tell them that "Yes, it's probably possible", then toss it back to
them for a better definition of what they want.
2)  Define the rules yourself by telling them the means by which this
can most likely be done, and then ask them to fit what they want into
that.

Rick

On Tue, Jun 24, 2008 at 8:11 AM, Robert Molenda
<[EMAIL PROTECTED]> wrote:

** 

I agree with Rick... Could be easy - could be next to impossible...

 

DSO is OK provided that the systems are configured the same - same
fields - same configuration data - same-same...

 

Web Services is probably the best method to do "Ticket Passing" which is
what I have to assume you are referring to between the two companies.
Works fine over a secure vpn tunnel as well. Only issue is
host-name-resolution...

 

You must create a common "interface" that will be used on 'both sides'
to send / receive the data and then custom workflow on each end to
'store the data' in the appropriate form + format + field definitions.

 

More 'details' would be helpful - you could actually get away with not
even transfering the tickets - however using web-services to create a
remote view into the other system, etc. All depends upon the
requirements.

 

HTH

 

Robert Molenda

On Tue, Jun 24, 2008 at 7:50 AM, Rick Cook <[EMAIL PROTECTED]> wrote:

** John, "integration" is, as you said, pretty vague.  Perhaps once you
have a better idea of its scale and definition, we might be able to give
better answers.  Could be anything from very simple to
you-gotta-be-kidding. 



Rick 

 

On Tue, Jun 24, 2008 at 7:40 AM, Reiser, John J <[EMAIL PROTECTED]>
wrote:

Hello Listers,

Current configuration
ARS 6.3 Patch 014
Midtier 6.3 Patch 021
MS SQL Server 2000

Upgrade path
ARS 7.1
Midtier 7
MS SQL Server 2000 maybe higher

I know this is a long shot but has anyone put together an integration
between two different ARSystem server

Re: Integrating with another company's ARSystem

[Reiser, John J]

Roger, Rick and Robert,
 
Thanks for the replies.
Yes it is vague.
Yes it will be a challenge.
Especially since the other system is a US Navy system and I am sure
security will be tight.
 
Right now this is "pie-in-the-sky" but that never stopped them before;^>
 
 
Robert, I have a question about your DSO statement. I thought the idea
behind DSO was also to allow you to connect to a different form
structure and still pass relevant data.
We are purchasing DSO for another project and they use ITSM, we use our
home grown Helpdesk. We just need to pass Ticket ID's as reference data
as well as problem summary and user info. This was suggested to us by
the Developers on the ITSM site.
 
Thanks,

John J. Reiser
Software Development Analyst
Remedy Administrator/Developer
Lockheed Martin - MS2
The star that burns twice as bright burns half as long.
Pay close attention and be illuminated by its brilliance. - paraphrased
by me



 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook
Sent: Tuesday, June 24, 2008 11:31 AM
To: arslist@ARSLIST.ORG
Subject: Re: Integrating with another company's ARSystem


** Excellent point about DSO.  I think the key here is being able to
establish either a secure gateway between the two AR servers or a common
middle ground (which means server, forms, etc.).  Since you have zero
dollars to spend on hardware, it looks like you should be investigating
how to tunnel from one AR server to the other in some way, like Robert
said, using some common data forms, assuming that the data is common
enough to make that possible.  Do you know anything about the other AR
System and it's applications?  If not, now would be a great time to
start finding out, so that you have the answers before anyone asks more
questions and defines unrealistic expectations for you.

Or, you could bypass AR System altogether, and create SQL views into the
DBs, and view them from a web page or something.  Like I said, until you
are given a better definition of what they want, it's really premature
to design the solution for it.

>From a business perspective, there are two tacks you can take:
1)  Tell them that "Yes, it's probably possible", then toss it back to
them for a better definition of what they want.
2)  Define the rules yourself by telling them the means by which this
can most likely be done, and then ask them to fit what they want into
that.

Rick


On Tue, Jun 24, 2008 at 8:11 AM, Robert Molenda
<[EMAIL PROTECTED]> wrote:


** 
I agree with Rick... Could be easy - could be next to
impossible...
 
DSO is OK provided that the systems are configured the same -
same fields - same configuration data - same-same...
 
Web Services is probably the best method to do "Ticket Passing"
which is what I have to assume you are referring to between the two
companies. Works fine over a secure vpn tunnel as well. Only issue is
host-name-resolution...
 
You must create a common "interface" that will be used on 'both
sides' to send / receive the data and then custom workflow on each end
to 'store the data' in the appropriate form + format + field
definitions.
 
More 'details' would be helpful - you could actually get away
with not even transfering the tickets - however using web-services to
create a remote view into the other system, etc. All depends upon the
requirements.
 
HTH
 
Robert Molenda


On Tue, Jun 24, 2008 at 7:50 AM, Rick Cook
<[EMAIL PROTECTED]> wrote:


** John, "integration" is, as you said, pretty vague.
Perhaps once you have a better idea of its scale and definition, we
might be able to give better answers.  Could be anything from very
simple to you-gotta-be-kidding. 


Rick 


On Tue, Jun 24, 2008 at 7:40 AM, Reiser, John J
<[EMAIL PROTECTED]> wrote:


Hello Listers,

Current configuration
ARS 6.3 Patch 014
Midtier 6.3 Patch 021
MS SQL Server 2000

Upgrade path
ARS 7.1
Midtier 7
MS SQL Server 2000 maybe higher

I know this is a long shot but has anyone put
together an integration
between two different ARSystem servers in two
different companies?
I'm guessing the only real solution would be to
use webservices. I don't
have anymore details other than " we must be
able to transfer
information between systems.

Oh, did I mention that we can only spend labor
dollars to accomplish
  

Re: Integrating with another company's ARSystem

[Rick Cook]

Excellent point about DSO.  I think the key here is being able to establish
either a secure gateway between the two AR servers or a common middle ground
(which means server, forms, etc.).  Since you have zero dollars to spend on
hardware, it looks like you should be investigating how to tunnel from one
AR server to the other in some way, like Robert said, using some common data
forms, assuming that the data is common enough to make that possible.  Do
you know anything about the other AR System and it's applications?  If not,
now would be a great time to start finding out, so that you have the answers
before anyone asks more questions and defines unrealistic expectations for
you.

Or, you could bypass AR System altogether, and create SQL views into the
DBs, and view them from a web page or something.  Like I said, until you are
given a better definition of what they want, it's really premature to design
the solution for it.

>From a business perspective, there are two tacks you can take:
1)  Tell them that "Yes, it's probably possible", then toss it back to them
for a better definition of what they want.
2)  Define the rules yourself by telling them the means by which this can
most likely be done, and then ask them to fit what they want into that.

Rick

On Tue, Jun 24, 2008 at 8:11 AM, Robert Molenda <[EMAIL PROTECTED]>
wrote:

> ** I agree with Rick... Could be easy - could be next to impossible...
>
> DSO is OK provided that the systems are configured the same - same fields -
> same configuration data - same-same...
>
> Web Services is probably the best method to do "Ticket Passing" which is
> what I have to assume you are referring to between the two companies. Works
> fine over a secure vpn tunnel as well. Only issue is host-name-resolution...
>
> You must create a common "interface" that will be used on 'both sides' to
> send / receive the data and then custom workflow on each end to 'store the
> data' in the appropriate form + format + field definitions.
>
> More 'details' would be helpful - you could actually get away with not even
> transfering the tickets - however using web-services to create a remote view
> into the other system, etc. All depends upon the requirements.
>
> HTH
>
> Robert Molenda
>
> On Tue, Jun 24, 2008 at 7:50 AM, Rick Cook <[EMAIL PROTECTED]> wrote:
>
>> ** John, "integration" is, as you said, pretty vague.  Perhaps once you
>> have a better idea of its scale and definition, we might be able to give
>> better answers.  Could be anything from very simple to you-gotta-be-kidding.
>>
>>
>> Rick
>>
>>
>> On Tue, Jun 24, 2008 at 7:40 AM, Reiser, John J <[EMAIL PROTECTED]>
>> wrote:
>>
>>> Hello Listers,
>>>
>>> Current configuration
>>> ARS 6.3 Patch 014
>>> Midtier 6.3 Patch 021
>>> MS SQL Server 2000
>>>
>>> Upgrade path
>>> ARS 7.1
>>> Midtier 7
>>> MS SQL Server 2000 maybe higher
>>>
>>> I know this is a long shot but has anyone put together an integration
>>> between two different ARSystem servers in two different companies?
>>> I'm guessing the only real solution would be to use webservices. I don't
>>> have anymore details other than " we must be able to transfer
>>> information between systems.
>>>
>>> Oh, did I mention that we can only spend labor dollars to accomplish
>>> this?
>>>
>>> I am just getting a taste of webservices inside one company and haven't
>>> gotten too far.
>>> Are there any issues with webservice publishing/consuming through the
>>> security firewalls?
>>>
>>> Sorry to be so general and I understand that the basic answer is
>>> probably "yes". I need to get a rough order of magnitude for such a
>>> requirement.
>>>
>>> TIA,
>>>
>>>
>>>
>>> John J. Reiser
>>> Software Development Analyst
>>> Remedy Administrator/Developer
>>> Lockheed Martin - MS2
>>> The star that burns twice as bright burns half as long.
>>> Pay close attention and be illuminated by its brilliance. - paraphrased
>>> by me
>>>
>>>
>>>
>>> ___
>>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>>> Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
>>>
>>
>> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
>> html___
>
>
>
>
> --
> If it were not for the gutter, my mind would be homeless! __Platinum
> Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Integrating with another company's ARSystem

[Robert Molenda]

I agree with Rick... Could be easy - could be next to impossible...

DSO is OK provided that the systems are configured the same - same fields -
same configuration data - same-same...

Web Services is probably the best method to do "Ticket Passing" which is
what I have to assume you are refering to between the two companies. Works
fine over a secure vpn tunnel as well. Only issue is host-name-resolution...

You must create a common "interface" that will be used on 'both sides' to
send / receive the data and then custom workflow on each end to 'store the
data' in the appropriate form + format + field definitions.

More 'details' would be helpful - you could actually get away with not even
transfering the tickets - however using web-services to create a remote view
into the other system, etc. All depends upon the requirements.

HTH

Robert Molenda

On Tue, Jun 24, 2008 at 7:50 AM, Rick Cook <[EMAIL PROTECTED]> wrote:

> ** John, "integration" is, as you said, pretty vague.  Perhaps once you
> have a better idea of its scale and definition, we might be able to give
> better answers.  Could be anything from very simple to you-gotta-be-kidding.
>
> Rick
>
>
> On Tue, Jun 24, 2008 at 7:40 AM, Reiser, John J <[EMAIL PROTECTED]>
> wrote:
>
>> Hello Listers,
>>
>> Current configuration
>> ARS 6.3 Patch 014
>> Midtier 6.3 Patch 021
>> MS SQL Server 2000
>>
>> Upgrade path
>> ARS 7.1
>> Midtier 7
>> MS SQL Server 2000 maybe higher
>>
>> I know this is a long shot but has anyone put together an integration
>> between two different ARSystem servers in two different companies?
>> I'm guessing the only real solution would be to use webservices. I don't
>> have anymore details other than " we must be able to transfer
>> information between systems.
>>
>> Oh, did I mention that we can only spend labor dollars to accomplish
>> this?
>>
>> I am just getting a taste of webservices inside one company and haven't
>> gotten too far.
>> Are there any issues with webservice publishing/consuming through the
>> security firewalls?
>>
>> Sorry to be so general and I understand that the basic answer is
>> probably "yes". I need to get a rough order of magnitude for such a
>> requirement.
>>
>> TIA,
>>
>>
>>
>> John J. Reiser
>> Software Development Analyst
>> Remedy Administrator/Developer
>> Lockheed Martin - MS2
>> The star that burns twice as bright burns half as long.
>> Pay close attention and be illuminated by its brilliance. - paraphrased
>> by me
>>
>>
>>
>> ___
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
>>
>
> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> html___




-- 
If it were not for the gutter, my mind would be homeless!

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: SQL Server huge translogs and very poor performance

[Hall Chad - chahal]

What kind of disk subsystem is your database on? Faster the better. But
also make sure your transaction log is on a completely separate set of
physical disks than your data file. That way they won't contend for the
same resources. If possible, keep the paging file and the OS on their
own dedicated disk(s) too.

 

And what RAID configuration are you using? 

 

Chad Hall  
(501) 342-2650



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Craig Carter
Sent: Tuesday, June 24, 2008 8:29 AM
To: arslist@ARSLIST.ORG
Subject: Re: SQL Server huge translogs and very poor performance

 

This may be obvious but you didn't specify what version of SQL, etc.  At
a minimum, you do have daily transaction log backups running right?
Unless you back up the logs on a regular basis (at least daily), they
will continue to grow and degrade performance.  Since you don't get
backups by default when you create a database, it is easy to overlook.

 

Second; we found one of our servers was set up with a very restrictive
and fixed Virtual Memory setting (paging file).  You may want to check
that and increase it if needed.

 

Since your servers are only 4GB, AWE memory allocation shouldn't be a
factor.  When you are running more than 4GB, turning that on helps a
lot.

 

If you have regular transaction log backups, the recommendation below
makes a lot of sense since you need to try and determine what is causing
the rapid growth.

 

Craig Carter

Software Engineer, RSP

 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of LJ Longwing
Sent: Monday, June 23, 2008 5:31 PM
To: arslist@ARSLIST.ORG
Subject: Re: SQL Server huge translogs and very poor performance

 

About the only tip I can give you is this.  Give yourself enough room
for your transaction logs.  They are growing for a reason...you could
try turning on sql logging to see what your server is busy doing because
the logs shouldn't be growing if your app isn't doing anything.  Your
DBA should be able to tell you who is connected to the db, and your sql
logs should be able to tell you who is making modifications to what
values.

 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Brian Gillock
Sent: Monday, June 23, 2008 5:23 PM
To: arslist@ARSLIST.ORG
Subject: SQL Server huge translogs and very poor performance

** 

Hey Listers,

Does anyone have any tips for maintaining transaction
logs in SQL Server?  Ours seem to growing at an insane rate and nothing
our DBAs are doing is helping at all.  And I'm continually getting time
outs when trying to save workflow.  And that is without any users.
There is nothing special setup in development and I can do a backup,
truncating the logs and that helps for a while.  In production, however,
we have log mirroring setup for DR purposes.  It's killing me.  The DB
and AR box are both on their own dual quad core servers with 4GB RAM, so
I don't think it's a resource issue.  Any advice is appreciated.

 

Thanks!

Brian

 

 

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___ 

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___ __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the
Answers Are" html___
***
The information contained in this communication is confidential, is
intended only for the use of the recipient named above, and may be legally
privileged.

If the reader of this message is not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.

If you have received this communication in error, please resend this
communication to the sender and delete the original message or any copy
of it from your computer system.

Thank You.


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Integrating with another company's ARSystem

[Rick Cook]

John, "integration" is, as you said, pretty vague.  Perhaps once you have a
better idea of its scale and definition, we might be able to give better
answers.  Could be anything from very simple to you-gotta-be-kidding.

Rick

On Tue, Jun 24, 2008 at 7:40 AM, Reiser, John J <[EMAIL PROTECTED]>
wrote:

> Hello Listers,
>
> Current configuration
> ARS 6.3 Patch 014
> Midtier 6.3 Patch 021
> MS SQL Server 2000
>
> Upgrade path
> ARS 7.1
> Midtier 7
> MS SQL Server 2000 maybe higher
>
> I know this is a long shot but has anyone put together an integration
> between two different ARSystem servers in two different companies?
> I'm guessing the only real solution would be to use webservices. I don't
> have anymore details other than " we must be able to transfer
> information between systems.
>
> Oh, did I mention that we can only spend labor dollars to accomplish
> this?
>
> I am just getting a taste of webservices inside one company and haven't
> gotten too far.
> Are there any issues with webservice publishing/consuming through the
> security firewalls?
>
> Sorry to be so general and I understand that the basic answer is
> probably "yes". I need to get a rough order of magnitude for such a
> requirement.
>
> TIA,
>
>
>
> John J. Reiser
> Software Development Analyst
> Remedy Administrator/Developer
> Lockheed Martin - MS2
> The star that burns twice as bright burns half as long.
> Pay close attention and be illuminated by its brilliance. - paraphrased
> by me
>
>
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
>

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Integrating with another company's ARSystem

[Nall, Roger]

John,

We use DSO to integrate 4 different ARSYSTEM servers. It works great. I
would think that web services would work as well. As for the firewall
issues as long as the systems are on the same or trusted networks I
would think you would be okay. Just a guess on my part.

HTH,

Roger A. Nall 
Manager, OSSNMS Remedy 
T-Mobile, USA 
Desk: 813-348-2556 
Cell: 973-652-6723 
FAX: 813-348-2565 
sf49fanv AIM IM 
RogerNall Yahoo IM 
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Reiser, John J
Sent: Tuesday, June 24, 2008 10:40 AM
To: arslist@ARSLIST.ORG
Subject: Integrating with another company's ARSystem

Hello Listers,

Current configuration
ARS 6.3 Patch 014
Midtier 6.3 Patch 021
MS SQL Server 2000

Upgrade path
ARS 7.1
Midtier 7
MS SQL Server 2000 maybe higher
 
I know this is a long shot but has anyone put together an integration
between two different ARSystem servers in two different companies?
I'm guessing the only real solution would be to use webservices. I don't
have anymore details other than " we must be able to transfer
information between systems.

Oh, did I mention that we can only spend labor dollars to accomplish
this?

I am just getting a taste of webservices inside one company and haven't
gotten too far.
Are there any issues with webservice publishing/consuming through the
security firewalls?

Sorry to be so general and I understand that the basic answer is
probably "yes". I need to get a rough order of magnitude for such a
requirement.

TIA,



John J. Reiser
Software Development Analyst
Remedy Administrator/Developer
Lockheed Martin - MS2
The star that burns twice as bright burns half as long.
Pay close attention and be illuminated by its brilliance. - paraphrased
by me 
 


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Integrating with another company's ARSystem

[Reiser, John J]

Hello Listers,

Current configuration
ARS 6.3 Patch 014
Midtier 6.3 Patch 021
MS SQL Server 2000

Upgrade path
ARS 7.1
Midtier 7
MS SQL Server 2000 maybe higher
 
I know this is a long shot but has anyone put together an integration
between two different ARSystem servers in two different companies?
I'm guessing the only real solution would be to use webservices. I don't
have anymore details other than " we must be able to transfer
information between systems.

Oh, did I mention that we can only spend labor dollars to accomplish
this?

I am just getting a taste of webservices inside one company and haven't
gotten too far.
Are there any issues with webservice publishing/consuming through the
security firewalls?

Sorry to be so general and I understand that the basic answer is
probably "yes". I need to get a rough order of magnitude for such a
requirement.

TIA,



John J. Reiser
Software Development Analyst
Remedy Administrator/Developer
Lockheed Martin - MS2
The star that burns twice as bright burns half as long.
Pay close attention and be illuminated by its brilliance. - paraphrased
by me 
 

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Need Stats on ITSM Licensing Usage

[Barber, David]

Very, very true, I'm still getting calls a few years on  

-Original Message-
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
Behalf Of Rosemary
Sent: 23 June 2008 22:03
To: arslist@ARSLIST.ORG
Subject: Re: Need Stats on ITSM Licensing Usage


** It is good, but be prepared for a phonecall from their salespeople after 
using the demo version.


On 6/24/08, Barber, David < [EMAIL PROTECTED]> wrote: 

** 
http://rrr.se/en/ - the rrrLicense tool is pretty good.
 
Regards
 
Dave

-Original Message-
From: Action Request System discussion list(ARSList) [mailto: [EMAIL PROTECTED] 
Behalf Of Ranjith
Sent: 23 June 2008 14:47
To: arslist@ARSLIST.ORG
Subject: Need Stats on ITSM Licensing Usage


** 

Hi All,

How can we get a report that shows us the usage of all of the different ITSM 
License types?

Thanks,
Ranjith


__Platinum Sponsor: www.rmsportal.com   ARSlist: 
"Where the Answers Are" html___ 


This e-mail has been scanned for viruses by the Cable & Wireless e-mail 
security system - powered by MessageLabs. For more information on a proactive 
managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ 

The information contained in this e-mail is confidential and may also be 
subject to legal privilege. It is intended only for the recipient(s) named 
above. If you are not named above as a recipient, you must not read, copy, 
disclose, forward or otherwise use the information contained in this email. If 
you have received this e-mail in error, please notify the sender (whose contact 
details are above) immediately by reply e-mail and delete the message and any 
attachments without retaining any copies.

Cable and Wireless plc 
Registered in England and Wales.Company Number 238525 
Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ
 
__Platinum Sponsor: www.rmsportal.com   ARSlist: 
"Where the Answers Are" html___ 


__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ 


This e-mail has been scanned for viruses by the Cable & Wireless e-mail 
security system - powered by MessageLabs. For more information on a proactive 
managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ 

The information contained in this e-mail is confidential and may also be 
subject to legal privilege. It is intended only for the recipient(s) named 
above. If you are not named above as a recipient, you must not read, copy, 
disclose, forward or otherwise use the information contained in this email. If 
you have received this e-mail in error, please notify the sender (whose contact 
details are above) immediately by reply e-mail and delete the message and any 
attachments without retaining any copies.
 
Cable and Wireless plc 
Registered in England and Wales.Company Number 238525 
Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: ITSM 7: Multitenancy, Permissions, Roles. Need OOB info and customization ideas

[Rabi Tripathi]

Christopher,
Wow, you guys have done a lot of work on this. I can
imagine the efforts that went into analyzing and
documenting the details.

I quickly looked at a few things, and I can see you
have a lot of useful info. Thank you for the link.

The main issue I see (with BMC's documentation) is
that a lot of the information (but not all) is there
in bits and pieces all over the place. BMC never puts
it together in a place for you to understand the big
picture in full and to get an understanding of
implications of various choices.

I see that with great diagrams etc you have tried to
accomplish exactly that. I will be going back to your
site a lot. I am guessing that your advanced training
(PhD) may have pushed you towards ripping this beast
apart to understand it and fully utilize it, rather
than confining yourself and your implementation to the
limited understanding that BMC offers in its doc. :)

Thanks again. I will share with you anything useful I
may come across at my end.


--- strauss <[EMAIL PROTECTED]> wrote:

> You are welcome to study all of the multi-tenancy
> docs that we have put
> online so far, as we continue to refine our
> customizations to IM to get
> it to work the way we need it to.  All of the
> multi-tenancy docs and the
> new permissions write-up I "finished" today are at
> http://arsweb4.ars.unt.edu/index_prod.htm in the
> section titled
> "UNT-Specific Documentation for Multi-Tenancy in the
> UNT BMC Remedy ITSM
> 7.x system." We are still trying to beat some of the
> cross-company
> assignment problems into submission. There is even a
> new explanation of
> our initial implementation of SLM 7.1, which is
> almost as much fun to
> work with as multi-tenancy.  In fact, it has to work
> very differently in
> a multi-tenancy environment, and we expect it to
> evolve a lot over the
> coming year as we learn more about it.
> 
> Let me know if got any of the concepts wrong - they
> are so well
> documented (NOT), and some of my reverse-engineering
> efforts have been
> superficial due to lack of time/resources that were
> instead spent fixing
> bugs in the OOTB app that never should have left the
> developers'
> workstations. I must admit that we have had trouble
> understanding some
> of the implications of our multi-tenancy model until
> real users started
> trying to do real work, and found that they could
> not. We didn't realize
> just how shallow the multi-tenancy capabilities of
> the OOTB app really
> are until we got it into production.
> 
> Christopher Strauss, Ph.D.
> Call Tracking Administration Manager
> University of North Texas Computing & IT Center
> http://itsm.unt.edu/
> 
> > -Original Message-
> > From: Action Request System discussion
> list(ARSList)
> > [mailto:[EMAIL PROTECTED] On Behalf Of Rabi
> Tripathi
> > Sent: Monday, June 23, 2008 10:58 PM
> > To: arslist@ARSLIST.ORG
> > Subject: ITSM 7: Multitenancy, Permissions, Roles.
> Need OOB info and
> > customization ideas
> > 
> > Hi folks,
> > I am looking at extending the ITSM 7's scheme for
> data
> > and rules partitioning (in other words,
> permissions)
> > to satisfy a customer's requirements.
> > 
> > I am looking for info on ITSM 7's OOB capabilities
> as
> > well ideas for modifications/enhancements.
> > 
> > I need to enhance the per company scheme of
> setting
> > data access permissions to take it to business
> units
> > within companies.
> > 
> > I also need to enhance specification and
> maintenance
> > of access rules for data to be more granular and
> less
> > onerous at the same time.
> > 
> > The main gaps between what customer needs and
> what's
> > in ITSM 7 are:
> > (1)multi-tenancy goes only so far. If a company is
> > supporting many other companies, business units
> within
> > those companies can not be segregated for data
> access
> > etc. In the customer's world, per company is not
> > specific enough.
> > 
> > (2)if you use recommended solution of having
> business
> > units themselves defined as companies, it gets
> > awkward, for the simple reason that this is a
> > workaround, not a good solution.  Bob Backline may
> > need access to 10 BUs within a company and 20 in
> > another. Who's going to maintain his and his
> > colleagues access list. He can't see their tickets
> > together in his console.
> > Plenty of other issues, such as reports etc. It
> will
> > be harder to do anything to a company as a whole.
> > 
> > (3)Company access can be specified at people
> level,
> > not group/organization level.
> > 
> > (4)Documentation issue--whatever capabilities ITSM
> has
> > for data/rules partitioning is not explained in
> full
> > anywhere . (see my list as to what I have seen so
> far)
> > 
> > 
> > So, I am looking for anything that will help
> me
> > fully understand OOB capabilities*** And any ideas
> on
> > customization to further enhance how tenancy,
> roles
> > etc can better segregate data and allow better
> control
> > of access to system's features. Ok, I am being

Re: SQL Server huge translogs and very poor performance

[Craig Carter]

This may be obvious but you didn't specify what version of SQL, etc.  At
a minimum, you do have daily transaction log backups running right?
Unless you back up the logs on a regular basis (at least daily), they
will continue to grow and degrade performance.  Since you don't get
backups by default when you create a database, it is easy to overlook.

 

Second; we found one of our servers was set up with a very restrictive
and fixed Virtual Memory setting (paging file).  You may want to check
that and increase it if needed.

 

Since your servers are only 4GB, AWE memory allocation shouldn't be a
factor.  When you are running more than 4GB, turning that on helps a
lot.

 

If you have regular transaction log backups, the recommendation below
makes a lot of sense since you need to try and determine what is causing
the rapid growth.

 

Craig Carter

Software Engineer, RSP

 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of LJ Longwing
Sent: Monday, June 23, 2008 5:31 PM
To: arslist@ARSLIST.ORG
Subject: Re: SQL Server huge translogs and very poor performance

 

About the only tip I can give you is this.  Give yourself enough room
for your transaction logs.  They are growing for a reason...you could
try turning on sql logging to see what your server is busy doing because
the logs shouldn't be growing if your app isn't doing anything.  Your
DBA should be able to tell you who is connected to the db, and your sql
logs should be able to tell you who is making modifications to what
values.

 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Brian Gillock
Sent: Monday, June 23, 2008 5:23 PM
To: arslist@ARSLIST.ORG
Subject: SQL Server huge translogs and very poor performance

** 

Hey Listers,

Does anyone have any tips for maintaining transaction
logs in SQL Server?  Ours seem to growing at an insane rate and nothing
our DBAs are doing is helping at all.  And I'm continually getting time
outs when trying to save workflow.  And that is without any users.
There is nothing special setup in development and I can do a backup,
truncating the logs and that helps for a while.  In production, however,
we have log mirroring setup for DR purposes.  It's killing me.  The DB
and AR box are both on their own dual quad core servers with 4GB RAM, so
I don't think it's a resource issue.  Any advice is appreciated.

 

Thanks!

Brian

 

 

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___ 

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: MAPILogonEx Failed - Unable to login to MAPI (365,868 records on AR System Email Error Logs)

[Craig Carter]

We've had this problem for years--not only will it suddenly fail to
connect to MAPI, we have instances where the service just hangs.  It
happened on v6 and currently happens on 7.0.1P5 as well (as you noted).

I finally created an SSIS package that runs every 15 minutes and looks
at the Email Messages form to determine if there are any emails that
were created more than 10 minutes previous (should normally not be any
since we poll every minute and it has no problem keeping up).  When
found, it cycles the Email Engine service.  Since the new version of the
Email Engine sets all messages to "Error" now when it loses connection
(by design according to BMC), this package resets all "Error" back to
"Yes" before restarting the service and increments an attempts counter
on each message (used an existing counter field in the form).

The package sets the "Send Message" flag to "No" for any messages that
fail to be sent after three attempts (due to real errors like bad email
address, etc) so they do not build up and cause the service to restart
needlessly.  I also check for messages older than 45 minutes and if
found, send an email alert to the administrators to check the service
and email form.  (Service may suddenly be failing to start due to a
password change, etc).

Since implementing this, we've no longer had to baby-sit the service.

Craig Carter
Software Engineer, RSP

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Hall Chad - chahal
Sent: Monday, June 23, 2008 8:58 AM
To: arslist@ARSLIST.ORG
Subject: Re: MAPILogonEx Failed - Unable to login to MAPI (365,868
records on AR System Email Error Logs)

We get this same error sporadically and cycling the Email Engine service
always clears it up. We're on 7.0.1 patch 5, but had the same problem on
6.3. It's frustrating, I know. BMC has never figured out what the cause
is. So we only use MAPI for incoming mail. We use SMTP for outgoing
because it's more stable.

Chad Hall  
(501) 342-2650


-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Elinore AR
Sent: Sunday, June 22, 2008 10:28 PM
To: arslist@ARSLIST.ORG
Subject: MAPILogonEx Failed - Unable to login to MAPI (365,868 records
on AR System Email Error Logs)

hi all, can someone help us? we don't know what is causing the
humongous error email log that is being dumped to/by our server. i'm
definitely positive we did not attempt sending any emails this many
since we are only on devel right now.

i checked and half (182,934!) of the record says this:

Message Type*: SEVERE
Message Number*: 0
Generated By*: Mail Box
Message Test:

MAPILogonEx Failed - Unable to login to MAPI
javax.mail.MessagingException: MAPILogonEx Failed - Unable to login to
MAPI
at com.remedy.mail.mapi.MAPINative.getStore(Native Method)
at com.remedy.mail.mapi.MAPIStore.connect(MAPIStore.java:145)
at com.remedy.mail.mapi.MAPIStore.connect(MAPIStore.java:165)
at
com.remedy.arsys.emaildaemon.ReceiverModule.initializeIncommingMailbox(R
eceiverModule.java:
1805)
at
com.remedy.arsys.emaildaemon.ReceiverModule.doWork(ReceiverModule.java:
206)
at
com.remedy.arsys.emaildaemon.ThreadBase.run(ThreadBase.java:268)
at java.lang.Thread.run(Unknown Source)

and the other half is:

Message Type*: INFO
Message Number*: 29
Generated By*: AR System Email Daemon
Message Test:

Incoming message queue size: 0

has anyone ever encountered this error before? have we missed on an
important configuration or something? we'd appreciate any help! thanks
in advance.

~ elinore


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

*
The information contained in this communication is confidential, is
intended only for the use of the recipient named above, and may be
legally privileged.

If the reader of this message is not the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.

If you have received this communication in error, please resend this
communication to the sender and delete the original message or any copy
of it from your computer system.

Thank you.

*


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: NULL pointer error when consuming a web service

[Frex Popo]

Thanks Carey.. 
 
I tested this on 7.1 and it works but not on 6.3.
 
The problem was a couple of missing jar files.
 
xercesImpl.jar
xml-apis.jar 
 
Just in case somone hits the same problem :-)
frex


--- En date de : Mer 11.6.08, Carey Matthew Black <[EMAIL PROTECTED]> a écrit :

De: Carey Matthew Black <[EMAIL PROTECTED]>
Objet: Re: NULL pointer error when consuming a web service
À: arslist@ARSLIST.ORG
Date: Mercredi 11 Juin 2008, 15h55

I would bet that the XML that you are sending either does not have a
block like this

"


user_name
pwd_str




  wrote:
> **
>
> Dear all,
>
>
>
> I have an ARS6.3 installed on WIN2000 OS with an Oracle9 DB. The Mid-Tier
is
> also installed on the same machine as the Remedy server.
>
>
>
> I am attempting to send some data to the remedy server using a Web Service
> and getting the following error:
>
>
>
> soapenv:Server.userException
>
> java.lang.NullPointerException
>
>
>
> I tried to simplify things by using a simple form with a character field.
I
> used both the get and create operations and end up with the same error. I
> thought this could be due to some invalid characters either in the data or
> the field names but it wasn't to be.
>
>
>
> Here is the xml sent to the remedy Web Server:
>
>
>
> 
>
> http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>
> 
>
> 
>
> soapenv:Server.userException
>
> java.lang.NullPointerException
>
> 
>
> 
>
> 
>
> 
>
>
>
> Have you seen this error before?
>
>
>
> Ah! I am using SOAPSonar to test my Web Service. I used the same client in
> the past to test some SAP Web Service and it worked fine.
>
>
>
> Many thanks in advance
>
>
>
> frex
>
>
>
> 
> Envoyé avec Yahoo! Mail.
> Une boite mail plus intelligente. __Platinum Sponsor: www.rmsportal.com
> ARSlist: "Where the Answers Are" html___

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"


  
_ 
Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"