Showing posts with label remedy integration. Show all posts
Showing posts with label remedy integration. Show all posts

Monday, October 19, 2009

Remedy Integration - Common Operations

You can call it step 1 of remedy integration with your application (using Java API, C, .NET API's are also avaiable)

CREATING CONTEXT

This operation / step is to set a context which consists of server ip, port number, user name, password and so on. Fill in the details accordingly

// Remedy Server IP
public static String ARS_SERVER = "";

// Remedy Port Number
public static int ARS_PORT = "";

// Remedy RPC number, usually 0
public statis int ARS_RPC = "";

// Remedy Language, usually blank
public static String ARS_LANGUAGE = “”;

// Remedy Form Name
public static String ARS_FORMNAME =”SAMPLE_JOE_FORM”;

// Remedy User ID
public static String ARS_USER = “joelj”;

// Remedy User Password
public static String ARS_PASSWORD = “mypass”;

ARServer context = new ARServerUser(ARS_USER, ARS_PASSWORD, ARS_LANGUAGE, ARS_SERVER);

Util.ARSetServerPort(context, new NameID(context.getServer()), ARS_PORT, ARS_RPC);

Following posts will talk about Creating, Updating and Retreiving remedy tickets.

Make sure you create a sample form in your (dev) remedy server to play around.

Tuesday, October 13, 2009

Remedy Integration - Common errors and issues

MessageNum: 90
Message not in catalog; Message number = 90
RPC: Rpcbind failure - RPC: Timed out

If you are getting errors above while integrating your app with Remedy then you should
continue reading.

Default, Remedy API calls underneath C API which uses RPC to communicate to the Remedy server.
It would not cause any problem if our software and Remedy server are loaded in the same machine or
there is no firewall or any kind of device that blocks the RPC communication between our software
and the Remedy server. Let just take a moment to look at how RPC works.
Each host that contains remote program runs a port-mapping server that listens on a well-known port (111).
The client contacts the port-mapper on its dedicated port, and sends the remote program number
and version number. The port mapper starts the remote program on a free port and sends that port number
to the client. The client then contacts the remote program on the specified port.

Because of how RPC works, clients would not know the free port that the server will use until run-time,
and clients would potentially receive a different port from the port-mapper every time.
This has raised a red alert in a network which has firewall because firewall administrator has
to open pretty much very single port to get the RPC work.

So if there is a firewall between our software and the remedy server, you will only get timeout errors as above.

Whats the workaround for this?

Specify the port number the Remedy server is listening on as follows prior to pass the ARServerUser object to Remedy.

Util.ARSetServerPort(ARServerUser context, NameID server, int port, int progNum)