First, the overall structure of the database schema is completely
different. From within the AR System, the core tables are actlink,
filter, etc. One the Magic side, there are a couple of types of core
tables, starting with NAMSys, and then SMSys.
The 'user' tables are also different, as within the AR System most
developers are used to seeing the typical Tx, Hx, and Bx(n) tables.
Within Magic, however, this is not the case. Tables within the Magic
database are typically a bit more readable. If you're using the
'Incident Management' component of Magic (most people do, yes?) the
table that you're after would be called '_TELMASTE_' aka
'_SMDBA_._TELMASTE_' because the user tables are actually owned by
another database user called '_SMDBA_' (which is actually a role as well).
Now - getting information out of Magic is probably best done by creating
a vendor form that uses one of the many views that Magic puts out there.
This is because a lot of the referential lookup schtuff is done for you.
Magic is a bit more normalized than the AR System, so the client
information that an end user sees on a form is stored not in
_SMDBA_._TELMASTE_ along with the other ticket data, but rather in
_SMDBA_._CUSTOMER_ and a 'Sequence' is used as a foreign key to link it
to the correct client row. This same premise is true of the user defined
status, incident descriptions, etc.
Magic will create a new view for each group - for each table. If you
have four our five groups, the database will have a multitude of views.
This is how controlling access to specific row sets was accomplished.
Within Remedy, it's called 'implicit permissions.' On the Magic side,
it's called 'data segregation.' This is important because you need to
consider which set of views to use by the ownership of the object. In
this case, if I were going to do this, I would use the 'Incident' view
that is owned by the '_SMDBA_' user (assuming you need to see all of the
data).
Actually creating a ticket from the AR System, and plugging it into
Magic won't work. First, there is the issue of the Sequence, which has
to be unique (similar in concept to the Entry-Id, err... Umm..
RequestId). If a record is created that has the same Sequence, the end
users will receive an error message when they try to create a new row in
the same Magic table that is used in your vendor form. So, you're AR
System workflow would first have to perform a lookup against the
SMSYSRECNUM table to retrieve the next sequence that would be available
for that particular table, and then update the SMSYSRECNUM table after
incrementing the value. Once this is done, then - again - because the
data is a bit more normalized, your AR System workflow would then have
to lookup and retrieve the sequence for the customer, status, and
subject rows. Finally, this could then become a part of the new incident
row. But then, this does not take into consideration whether or not your
customer is new and present in your AR System, but not your Magic
system. Of course, this does not necessarily address any sorts of issues
with workflow.
From within the AR System, there are several types - Active Links,
Filters, Menus, Escalations, and on a higher level Guides - form the
base of 'getting er done.' Within Magic, none of those exist. In Magic,
there is one type called 'Business Rules.' Business Rules do not have a
firing order, nor do they have a whole lot to do with the client side.
Sure, there are 'Client Side Business Rules' but these are far more
limited in what they can do when compared with an Active Link. Now here
is the kick in the guts - if you decide to use a sequel insert, you
bypass any sort of business rules that might have been set up -
including notification rules. This needs to be considered.
Are you following the obvious here? Attempting to use any sort of direct
sequel to insert row data into a Magic table is a bad idea (unless you
really, really know both schemas very well and have a burning desire to
send - add a Carl Sagan accent to this next line - 'billions and
billions of innocent electrons to their needless deaths'....). Inserting
your new row into a temp table and then picking it up with Magic is a
crap-shoot as well, because as of version eight, Magic does NOT support
using a linked table.
If you need to insert data from the AR System into Magic, one option
that you would have would be to use a stored procedure on the SQL Server
side. The reason being simple - the procedure would need to perform the
additional lookups and integrity checks against the other tables from
with the MagicDB. Please note that the actual complexity of such a
procedure is dependent upon the number of other tables that are
referenced in the ticket that you're actually working with. It's not
impossible to accomplish, but I didn't say that it would be a two minute
job either. Make friends with your DBA. Feed her/him lots of pizza and
free beer. Drop a gift of a statue of the Great Digital God - Com-pu-ta
- from the Temple of High Tech on their desk. You get the idea.
Once you have your procedure in place, use a filter to pass the record
contents to the procedure for execution. This in itself has a design
problem, as a filter cannot take the results of a direct sql action.
Better to have your procedure write the results to a logging table, and
then pick the results up afterwards in 'set fields action.' I suppose
that you could try getting around this limitation by using an active
link and a button. (Like Perl, there is more than one way to do it.) Of
course, there is still the business rule issue...
Another option that you would have is to use the web service component
that is supposed to be a part of version nine, or even version ten which
is supposed to be around the corner. I don't know a whole lot about this
yet, and have only heard of it's existence. Your milage will most
definitely vary from the posted norms.
Another option is to use the AR System API, and the Magic (ggrrr....)
API. I snarl a bit there because - whereas the AR System API is free for
customer integrations, the Magic version is not and requires that you
have a license for the option on your server. If you go the API route,
it would get you around the business rule problem, and you could develop
a sort of middle-ware layer that would allow you to transfer tickets
back and forth. Of course, the option would not be real time and your
development might very well be in VBScript, since this is pretty common
when the Magic API gets the dust shaken off of it. Just a thought...
Email is certainly an option for creating tickets. Magic can pick an
email up and create a ticket form it. Just make sure that the content of
the email is in plain text only - otherwise your ticket data is going to
look like mud, since the email program that handles incoming email
messages for Magic does not support HTML or RTF formats.
Just some thoughts... If you have any specific questions, send me an
email off the list.
HTH.
Sam Rx wrote:
**
Possible integrations
Remedy -----> Magic
1. Direct SQL Level
2. There is something called Magic Interface wizard (you can
say this is small EIE)
I am not sure is it will fire the Business rules that are created to
execure in submit of a incident (ticket)
3. Emails (you can create only incidents using this in magic)
In case you need any expert suggesation on the interface wizard then i
request to visit the magic user group (magicsolutions) on yahoo.
Magic ------> Remedy
1. Emails
2. EIE (your submit filters are taken care of)
HTH
On 10/18/06, *Frank, Gordon M Mr NISO/Lockheed Martin*
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
**
Classification: _*UNCLASSIFIED*_
Caveats: NONE
Hello all,
I have never worked with Magic and was wondering if someone has
interfaced Remedy ARS with Magic. Is this feasible? Does it make
sense? What would be the gains of this type of configuration?
Just looking for some experienced info on Magic
Thanks up front,
Gordon Frank
US Army/Lockheed Martin
Classification: _*UNCLASSIFIED*_
Caveats: NONE
__20060125_______________________This posting was submitted with
HTML in it___
__20060125_______________________This posting was submitted with HTML
in it___
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
