Chanan, You did not mention what Version of ARS your using, but if your on the current version (v7) there are some really interesting options for your Java skills. There is a new type of ARS field call a Data Visualization Field (DVF). Basically this is an extensible field that allows a Java programmer the ability to extend the ARS environment form the client up. There is a defined "Plugin" type structure that lets your Java code "running" in the DVF to interact (signal) the current ARS Form that the User has open and to receive signals from the ARS form too. (So the interface is bidirectional.) The sky is really the limit.
However, before you dive in to DVF's you really should get the basics of ARS down. Give the PDF's a good read and feel free to ask questions when needed. Here is the two minute summary: 1) ARS is a fully integrated Client to DB environment. An ARS object is built using the Administrator Tool. (Think of it as an ARS IDE.) ARS Objects are used via the User Tool, or the Mid-Tier(web client). But the clients work 98% the same. The difference are mostly due to browser limitations. Example: The User Tool is a windows program that has access to OLE and DDE integration points. Browser do not, buy default, expose such integrations to web servers that the person is connected to. (And for good reason if you ask me. :) 2) ARS is based on a C API, but has Java ( JNI based ) wrappers to. There is also a third party maintaining a Perl wrapper (open sourced) around the C API as well. But you need to know exactly zero about the API to actually do 85% of the application development that is possible with ARS. :) The clients that are provided (Admin, User, Mid-Tier, Import) all use this API, and you have access to write your own client if you wanted to. A few have taken the time, but most find it a waste of time and effort. 3) There are a very small set of ARS Objects, but each is fairly complicated. Since you have a programming background you will be able to grasp them fairly quickly, but do not become over confident. There are subtle details and design patterns that you are not familiar with from traditional programming techniques. Admin Objects: Forms, Active Links, Filters, Escalations, Menus, Active Link Guides, Filter Guides, Web Services, Applications, Packing Lists, Flashboards(Variables, Data Sets, Flashboards), There are also other objects that you can optionally buy too. Distributed Server Option (DSO mappings) and the ability to display more than 5 Flashboards. But I personally think of a data row as an "ARS Object" too. ( and that idea is reflected in the Java API wrappers. :) And I would also add ARS Fields and Form Views to the standard set. Applications are mosly sets of ARS forms and maybe a few other things. (A few more "other things" are possible in "Deployable Applications" than in "Local Applications" too.) An ARS Form is UI and/or DB elements. An ARS form can map to zero or more DB tables. An ARS Form has one or more Views. (Think UI display and arrangement of ARS fields.) Active Links are ARS clients workflow. They can operate on and be triggered by ARS Fields or the user's actions. Filters are ARS server workflow. ( Think DB triggers and you have the right idea.) Escalations are time triggered ARS server workflow. They can, and often do, trigger Filters. Menus are, as you might expect, UI effects for menus in the clients. Guides (Active Link and Filters) are kind of like a "subroutine" or an addressable set of Active Links or Filters. Web Services are what they sound like. An ARS published Web Service interface. Packing Lists can be safely ignored for now. They are a way for an ARS developer to keep track of a set of ARS objects. ( and a few other uses, but you will rarely[almost never] use these objects in ARS development for application functionality.) And you can read up on the other objects. (Flashboards, DSO) 4) The ARS server is a transactional universe. Think of a single data row being altered at a time and you are half way there. There are 5 basic "server" transactions. Submit (Create a new record), Modify (update/alter an existing record), Delete (yea.. you guessed it), Get Entry, and Merge. Get Entry: This is an opportunity that the ARS developer gets to alter the data row before it is returned to the ARS client. However it is only used when the API call is made to only return a single data row. You likely will not need this transaction until you master Submit and Modify. Merge: This is a special transaction designed to allow ARS administrators/developers to Load (batch[Submit or Modify]) data. You likely will not need this in the short term. The ARS client that issues Merge transaction is ONLY the Import Tool. ARS is a proprietary environment that does not require programmer level skills to develop basic applications in. However the more skilled you are in programming the better and faster you will understand the environment and the more complex applications you can create and maintain. It is impossible to say if that is something that would interest you. Or if it is something that would be a good career choice for you. For what it is worth: I would say that it might take a skilled Java programmer as long as ... say.... 6-12 months to get a good working _mastery_ of ARS application development. That is if you work on it 40 hrs a week for the entire time. ( So I have obviously skipped a lot of details/subtlety above. I would suggest that you go read the concept and Admin/workflow product pdf's for more details.) Hope that helps give you a jump start in the ARS universe. -- 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 3/17/07, Chanan Berler <[EMAIL PROTECTED]> wrote:
thanks a lot for the quick answer the company uses Remedy which is very much new to me - the idea both the programming language. thanks Chanan Rick Cook-3 wrote: > > If you work for a company that is willing to look at and take advantage of > what Remedy can do, it can be a pretty good job, because the underlying > technology is both powerful and well-constructed. And you will find that > your Java skill don't have to fall by the wayside, because not only does > Remedy use Java, but you can write Java scripts to automate and enhance > some > functionality. > > Remedy is used on every contintent and in every kind of industry, and can > track any kind of issue. You are not locked into the applications the > vendor sells you - you can build your own, using the same engine that > BMC/Remedy uses to build the ones they sell. > > Rick > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Chanan Berler > Sent: Saturday, March 17, 2007 3:10 PM > To: arslist@ARSLIST.ORG > Subject: newbie to remedy - questions > > Hi All, > > As i said in my subject i am new to Remedy and wanted to ask some > questions > here: > > 1) is Remedy popular as other programming langauges? like C++ or Java? > > 2) i am in a position to work with Remedy, should i follow it? or try my > luck in looking > for another work place which works with java (which i am more > familiar). > > thanks > Chanan
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
