CA Service Management

Hello, I'm using the following structure for my input file to insert requests.  If I remove the ref_num it gives me a message that "Null field in logical key --cannot be used for update". If I remove it it still doesn't process it.  If I try to put a value in it pdm_load tries to update that record so that won't work.  How do I structure this so it treats them all as an INSERT>

TABLE Call_Req
external_system_ticket type active_flag
category log_agent requested_by customer status impact priority ref_num group_id summary description

Hello,

First off, we do not advise directly inserting ticket information via pdm_load into the Call_Req table.  Whenever a ticket is created, at least 7 or so tables are accessed to have associated materials included, such as the events table, activity logs and the like.  There is also additional processing that takes place when a ticket is created, such as increment of the Key Control table and notification handling, which if bypassed by direct insertion into the Call_Req table, will disrupt said processing and potentially corrupt your overall installation.

Can you describe what it is you are attempting to achieve here, and how would inserting the records into the Call_Req allow you to achieve your objective and goal?

I'm trying to insert a large number of requests....

Is the insertion of ticket data coming from another source, like another ticketing system?  Are you trying to build some kind of data migration action?

One method I can think of that may help is using pdm_text_cmd.  What this does is it will create/update ticket information from a text file input.  An example command you can try is this:

pdm_text_cmd -t REQUEST -o NEW -f file1.dat -u ServiceDesk

In this case, we are going to create a new request with input file "file1.dat" done by user "ServiceDesk".

The content of the file1.dat shown here in italics (this is a plaintext file you can create in Notepad and should have no special formatting in place)

%SUMMARY=Test Summary
%DESCRIPTION=Test Description

Please be wary of any required fields which are not included and vary per installation.  The above should work in an uncustomised install of Service Desk. 

This method will create one ticket at a time per input file.

In trying the above in my own test machine, we get this response:

C:\>pdm_text_cmd -t REQUEST -o NEW -f file1.dat -u ServiceDesk
AHD58021:Successfully Created Request 57.

Original Input:

%SUMMARY=Test Summary
%DESCRIPTION=Test Description
%FROM_USERID=ServiceDesk

I have to create a bunch of requests using data pulled from an external source.  I have the data already and I want to create requests  with it. Thousands of them in large batches and it needs to be repeatable. I also need to populate more than just the three fields you mentioned.

TABLE Call_Req
external_system_ticket type active_flag
category log_agent requested_by customer status impact priority ref_num group_id summary description
{ "HPOVSR:1003436" ,"R" ,"1" ,"pcat:404101","U'0D74E711B6906745812ACB51801BD135'","U'36E8D664D8491046B9114A6AD9CB7D0D'","U'36E8D664D8491046B9114A6AD9CB7D0D'","***" ,"0","1","0","U'255E62C0C83C494791E8B5168F4DED64'","summary" ,"Description " }

I will see if the fields you are interested in can also be included in the input file.  The parameters in the file are derived from the text_api.cfg which I believe carries most of the fields of interest.

As for a repeatable solution, one thing I can think of is building a batch script that could take in the parameters you are trying to implement and create a temp input file of the format I described, which can then be processed by pdm_text_cmd.  Once the temp input file is processed and ticket created, delete the file and continue onto the next entry.  Development of such a script though is outside the scope of Support and would require a Services engagement, as would the web services solution.

The things to keep in mind is that there is absolutely no supported way to do this using pdm_load or any sort of table insertion methodology. 

The following tech doc describes the fields that could be used via pdm_text_cmd to load ticket data.  Maileater uses the same tags defined in pdm_text_cmd.

Tags that can be used with Maileater 

To add to what David-Ng has indicated, the following post will assist you in using Web Services to create SDM tickets

Create a ticket using Web Services 

"With that I will also just give you a note of caution that CA Support is not able to assist you in creating web services apps, or troubleshooting custom web services apps as that is outside the scope of support."

Jerry, I think on a test install you may want to play with pdm_load create call requests. I tried this command

pdm_load -i -f insert.txt

with insert.txt as following:"

TABLE Call_Req
active_flag customer log_agent priority description status ref_num
{"1" ,"793ED69B4E87A545BD8E911834D829FC" ,"793ED69B4E87A545BD8E911834D829FC" ,"3" ,"my cr 1" ,"OP" ,""}
{"1" ,"793ED69B4E87A545BD8E911834D829FC" ,"793ED69B4E87A545BD8E911834D829FC" ,"3" ,"my cr 2" ,"OP" ,""}

"

and 2 call requests were created. Of course I can add more lines to create cr 3, cr 4 and so on.

Notice that you could add more fields to it, as needed.

Is this what you looked for? Thanks _Chi

That did work and is what I was looking for.

As long as you understand that this will put data into the Call_Req table but no business rules will be triggered. The tickets will have no open date, no log entry to indicate the ticket was created, no notifications to anyone that the ticket has been added, no service type associated.

To also add to Lindsay's observations, there is also a high chance of collision that could arise when using this approach to insert ticket data through pdm_load, especially as there will likely be web based users who are also creating tickets and may conflict with established ticket's reference numbers.  Further, there is also a long term problem of key sync issues arising as a result of using this method. 

By using pdm_load, I feel obliged to inform you of all risks that would come of using this method and the potential concerns that would arise as a result.