I'm using Perl's LWP to create tickets in WHD. Most of the time, the call takes > 2.5 minutes to receive a response, even though the request is received right away.
The json I'm passing in is something like:
{ "room": "",
"emailClient": true,
"emailTech": true,
"emailTechGroupLevel": false,
"emailGroupManager": false,
"emailCc": false,
"ccAddressesForTech": "",
"emailBcc": false,
"bccAddresses": "",
"subject": "peas",
"detail": "I like peas.",
"assignToCreatingTech": false,
"problemtype": { "type": "ProblemType", "id": XXX },
"isPrivate": false,
"sendEmail": false,
"location": { "type": "Location", "id": 1 },
"clientReporter": { "type": "Client", "id": XXX },
"statustype": { "type": "StatusType", "id": 1 },
"prioritytype": { "type": "PriorityType", "id": 3 } }
my $req = HTTP::Request->new('POST', $uri);
$req->header('Content-Type' => 'application/json');
$req->content($json);
my $lwp = LWP::UserAgent->new;
my $response = $lwp->request($req);
Eventually, this succeeds, and returns a valid ticket.
$ time ./test_whd_api.pl
| '_protocol' => 'HTTP/1.1', | |
| '_content' => '{"id":255675,"type":"Ticket","lastUpdated":"2013-06-14T16:38:32Z","locationId":1,"statusTypeId":1,"subject":"XXXXX"} |
',
| '_rc' => '201', |
[snip]
real 5m52.988s
user 0m0.086s
sys 0m0.034s
Is it normal for it to take this long to receive a response? Do most people just make an asynchronous request? In this case, I'd really prefer to know for sure that the call succeeded.
In the webhelpdesk log:
INFO [2013-06-13 17:25:31]<http-bio-443-exec-109> JobTicketController: Performing action named: create (Request = /helpdesk/WebObjects/Helpdesk.woa/ra/Tickets/?apiKey=xxxxxxxx)
ERROR [2013-06-13 17:25:31]<http-bio-443-exec-109> ERROR: Unable to get preference for job ticket: null
[followed by a java backtrace]
and then:
WARN [2013-06-13 17:25:33]<http-bio-443-exec-109> "JobTicket"@1569799888 expression took
2090 ms: SELECT t0.ASSET_ID, t0.ASSIGNED_TECH_ID, t0.BCC_ADDRESSES, t0.BILLING_RATE_ID,
t0.BILLING_TERM_ID, t0.CC_ADDRESS_FOR_CLIENT, t0.MAIL_CC_ADDRESS, t0.CLIENT_CREATOR_ID,
t0.CLIENT_ID, t0.CLOSE_DATE, t0.CUSTOM_1, t0.CUSTOM_2, t0.CUSTOM_3, t0.CUSTOM_4,
t0.DELETED, t0.DEPARTMENT_ID, t0.DISABLE_EMAIL_TO_ALL_CLIENTS, t0.DISABLE_EMAIL_TO_CLIENT,
t0.DISABLE_EMAIL_TO_CLIENT_AND_CC, t0.DISCOUNT, t0.DUE_DATE_OVERRIDE, t0.DUE_HOURS_MANUAL,
t0.ESCALATION_LEVEL, t0.FIRST_RESPONSE_DATE, t0.HAS_BEEN_REASSIGNED,
t0.INITIALIZED_CUSTOM_FIELDS, t0.IP_ADDRESS, t0.IS_ELIGIBLE_FOR_SURVEY, t0.IS_HOT,
t0.IS_PRIVATE, t0.IS_TAX_FREE, t0.JOB_COST, t0.JOB_TICKET_ID, t0.JOB_TIME,
t0.LABOR_TAX_RATE, t0.LAST_CLIENT_REMINDER_DATE, t0.LAST_CLIENT_UPDATE,
t0.LAST_EMAIL_SEND_DATE, t0.LAST_REMINDER_DATE, t0.LAST_STATUS_UPDATE_TIME,
t0.LAST_UPDATED, t0.LOCATION_ID, t0.LOGGED_BY_ID, t0.MERGED_PARENT_TICKET_ID, t0.MODEL_ID,
t0.ORIGINAL_TECH_ID, t0.PARENT_ID, t0.PHONE, t0.PO_NUMBER, t0.PRIORITY_TYPE_ID,
t0.PROBLEM_TYPE_ID, t0.QUESTION_TEXT, t0.REPORT_DATE, t0.ROOM, t0.SEND_BCC_EMAIL,
t0.SEND_CARBON_COPY, t0.SEND_CLIENT_EMAIL, t0.SEND_GROUP_MGR_EMAIL,
t0.SEND_LEVEL_TECH_EMAIL, t0.SEND_TECH_EMAIL, t0.SEND_TO_CLIENT_CC_LIST,
t0.SERVICE_TIME_ENABLED, t0.SHIPPING, t0.SHOW_DUE_DATE_ON_CALENDAR,
t0.STATUS_RED_NOTIFICATION_DT, t0.STATUS_TYPE_ID, t0.STATUS_YELLOW_NOTIFICATION_DT,
t0.SUBJECT, t0.SUBSCRIBER_ID, t0.SURVEY_RESPONSE_ID, t0.TASK_ELEMENT_COMPLETE,
t0.TASK_ELEMENT_ID, t0.TASK_RUN_ID, t0.TECH_GROUP_LEVEL_ID,
t0.TICKET_TIME_AS_OF_LAST_UPDATE, t0.TRAVEL_COST, t0.TRAVEL_RATE_ID, t0.TRAVEL_TIME,
t0.UPDATED_BY_TECH_FLAG, t0.UPDATED_FLAG, t0.USE_DUE_DATE_OVERRIDE_INTEGER,
t0.WORK_END_DATE, t0.WORK_START_DATE FROM whd.JOB_TICKET t0 WHERE t0.STATUS_TYPE_ID =
? withBindings: 1:1[statusTypeId]
ERROR [2013-06-13 17:25:36]<http-bio-443-exec-109> ERROR: Unable to get preference for job
ticket: null
Seems like a MySQL select is the root of the problem (notice how long that query takes) - looks like this will essentially select all tickets of the same status type?
Here's an 'explain' on that select (with status_type_id set to 1):
+----+-------------+-------+------+----------------+----------------+---------+-------+-------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+----------------+----------------+---------+-------+-------+-------------+
| 1 | SIMPLE | t0 | ref | STATUS_TYPE_ID | STATUS_TYPE_ID | 5 | const | 93859 | Using where |
+----+-------------+-------+------+----------------+----------------+---------+-------+-------+-------------+
If I use curl and don't follow the redirects, I get a 3XX right away; if I do follow the redirects, I get a 5XX error. However, the tickets submitted via the above method *do* get submitted; they just take 3 minutes to get an HTTP response.