일괄처리 REST API
WebSphere Application Server Liberty에는 일괄처리 작업을 관리하기 위한 RESTful 관리 인터페이스가 포함되어 있습니다.
일괄처리 작업과 연관되는 기본 조작은 제출(시작), 중지, 다시 시작 및 상태 보기입니다. HTTP REST 클라이언트를 사용하여 이러한 조작을 수행할 수 있습니다. 요청의 일부로 제출되거나 응답의 일부로 리턴되는 데이터는 JSON으로 형식화됩니다.
다음 예는 REST API로 수행할 수 있는 기능을 보여줍니다.
제출자 역할만 부여된 사용자 ID를 가진 REST API
HTTPS를 통해 REST API를 호출하는 사용자 ID에 batchSubmitter 역할에 대한 액세스 권한이 부여된 경우에는 GET("읽기") URL이 리턴하는 결과가 필터링됩니다. 제출자가 제출한 작업 인스턴스와 연관된 인스턴스 및 실행 데이터만 제출자에게 표시됩니다. 이와 대조적으로 batchAdmin 및 batchMonitor 역할에 대한 액세스 권한이 부여된 사용자 ID는 지정된 매개변수 세트와 함께 지정된 URL이 리턴하는 모든 인스턴스 및 실행 데이터를 볼 수 있습니다.
batchSubmitter 역할 액세스 권한만 있는 사용자 ID에게는 지정된 URL의 문서에서 설명된 대로 표준 매개변수를 사용하여 먼저 필터링한 결과를 표시합니다. 제출자 자신이 제출한 작업 인스턴스와 연관된 인스턴스 및 실행 데이터만을 리턴하여 추가로 필터링합니다.
자세한 정보는 Liberty 일괄처리 환경 보안을 참조하십시오.
작업 인스턴스
- GET /ibm/api/batch/jobinstances/
- 이 URI는 작업 인스턴스 목록을 리턴합니다. 조회 매개변수는 다음과 같습니다.
- page=[page number]: 리턴할 페이지(레코드의 서브세트)를 표시합니다. 기본값은 0입니다.
- pageSize=[number of records per page]: 페이지당 레코드 수를 표시합니다. 기본값은 50입니다.
- 샘플 요청:
https://localhost:9443/ibm/api/batch/jobinstances
https://localhost:9443/ibm/api/batch/jobinstances?page=13&pagesize=20
- 샘플 응답:
[ { "jobName":"test_sleepyBatchlet", "instanceId":7, "appName":"SimpleBatchJob#SimpleBatchJob.war", "submitter":"bob", "batchStatus":"COMPLETED", "jobXMLName":"test_sleepyBatchlet", "instanceState":"COMPLETED", "_links":[ { "rel":"self", "href":"https://localhost:9443/ibm/api/batch/jobinstances/7" }, { "rel":"job logs", "href":"https://localhost:9443/ibm/api/batch/jobinstances/7/joblogs" } ] }, { "jobName":"test_sleepyBatchlet", "instanceId":6, "appName":"SimpleBatchJob#SimpleBatchJob.war", "submitter":"bob", "batchStatus":"COMPLETED", "jobXMLName":"test_sleepyBatchlet", "instanceState":"COMPLETED", "_links":[ { "rel":"self", "href":"https://localhost:9443/ibm/api/batch/jobinstances/6" }, { "rel":"job logs", "href":"https://localhost:9443/ibm/api/batch/jobinstances/6/joblogs" } ] } ]
- GET /ibm/api/batch/v2/jobinstances/
- 이 URI는 다음의 조회 매개변수로 필터링된 작업 인스턴스의 목록을 리턴합니다.
- jobInstanceId=[instanceId]:[instanceId]: instanceId 범위 사이(경계값 포함)에 있는 작업 인스턴스를 리턴합니다.
- jobInstanceId=>[instanceId]: 제공된 instanceId보다 크거나 같은 작업 인스턴스를 리턴합니다.
- jobInstanceId=<[instanceId]: 제공된 instanceId보다 작거나 같은 작업 인스턴스를 리턴합니다.
- jobinstanceId=[instanceId],[instanceId],[instanceId]: 지정된 작업 인스턴스를 리턴합니다.
- createTime=[yyyy-MM-dd]:[yyy-MM-dd]: 날짜 범위 사이(경계값 포함)의 작업 인스턴스를 리턴합니다.
- createTime=[yyyy-MM-dd]: 제공된 날짜의 작업 인스턴스를 리턴합니다.
- createTime=>3d: 3일 전의 날짜에 또는 그 이후에 작성된 작업 인스턴스를 리턴합니다. 예를 들어, createTime은 3일 전 날짜의 시작보다 크거나 같습니다.
- createTime=<3d: 3일 전의 날짜에 또는 그 이전에 작성된 작업 인스턴스를 리턴합니다. 예를 들어, createTime은 3일 전 날짜의 종료보다 작거나 같습니다.
- instanceState=[state],[state]: 제공된 상태의 작업 인스턴스를 리턴합니다. 유효한 인스턴스 상태는 SUBMITTED, JMS_QUEUED, JMS_CONSUMED, DISPATCHED, FAILED, STOPPED, COMPLETED 및 ABANDONED입니다.
- exitStatus=[string]: 종료 상태 문자열과 일치하는 작업 인스턴스를 리턴합니다. 이 문자열 기준의 경우 문자열의 임의의 위치에 와일드카드(*) 연산자를 사용할 수 있습니다.
- page=[page number]: 리턴할 페이지(레코드의 서브세트)를 표시합니다. 기본값은 0입니다.
- pageSize=[number of records per page]: 페이지당 레코드 수를 표시합니다. 기본값은 50입니다.
참고: createTime을 포함하는 조회에서 서버 기본 시간대의 역할작업을 제출할 때 작업 인스턴스에 대한 createTime은 작업 저장소에 저장되며 UTC로 정규화됩니다. createTime=[yyyy-MM-dd] 또는 createTime=[yyyy-MM-dd]:[yyy-MM-dd]:에서와 같이 yyyy-MM-dd를 사용하여 날짜를 지정하는 경우, 작업 인스턴스 테이블 레코드의 createTime 값에 대해 일치시킬 수 있도록 yyyy-MM-dd 날짜 문자열을 UTC 시간의 특정 범위로 변환해야 합니다. 이 기능을 수행하기 위해, 애플리케이션은 REST 요청을 처리하는 서버의 기본 시간대를 사용합니다. 일치 대상인 UTC 시간 범위로 날짜 문자열을 변환하기 위해 사용되는 시간대가 바로 이 서버의 시간대입니다.
다음 표는 조회 매개변수 jobInstanceId=10:13에 의해 리턴되는 데이터를 보여줍니다.
* 작업 저장소가 UTC 형식으로 createTime을 저장하므로, 표에 있는 데이터는 특정 서버(예: "server1")의 서버 기본 시간대를 사용하여 형식화된 createTime을 표시한다는 점을 이해하는 것이 중요합니다. ("server1"과는) 다른 기본 시간대의 두 번째 서버의 관점에서 유사한 표를 작성한 경우에는 대응되는 시간대 기반 차이가 있는 다른 CREATETIME 열 값 세트가 표시됩니다. 이는 다음 예의 데이터베이스에서 UTC createTime 값으로 yyyy-MM-dd 날짜 문자열 매개변수를 맵핑하는 데 사용되는 REST 요청을 처리 중인 서버의 기본 시간대입니다.JOBINSTANCEID CREATETIME(server1 시간대에서 *) INSTANCESTATE EXITSTATUS 10 11-05-2015.01:10:00 COMPLETED SUCCESS 11 11-08-2014.02:20:00 COMPLETED SUCCESS 12 11-10-2015.03:30:00 FAILED FAILURE 13 11-11-2015:04:40:00 COMPLETED SUCCESS 다음 명령은 실행 대상인 서버와는 무관하게 동일한 결과를 리턴합니다.- jobInstanceId=11:13은 JOBINSTANCEID의 11, 12 및 13을 리턴합니다.
- jobInstanceId=>12는 JOBINSTANCEID의 12 및 13을 리턴합니다.
- jobInstanceId=<12는 JOBINSTANCEID의 11 및 12를 리턴합니다.
- jobInstanceId=11,12는 JOBINSTANCEID의 11 및 12를 리턴합니다.
- instanceState=FAILED는 JOBINSTANCEID 12를 리턴합니다.
- exitStatus=SUCCESS는 JOBINSTANCEID의 10, 11 및 13을 리턴합니다.
다음 명령은 서로 다른 기본 시간대를 지닌 서버에 대해 서로 다른 결과를 리턴할 수 있습니다. 이 예에서, 이는 서버의 기본 시간대로 11-11-2015:07:00:00의 날짜 및 시간에 "server1"(이전 표를 채우기 위해 사용되는 동일한 서버)에 대해 발행됩니다.- createTime=>2d는 JOBINSTANCEID의 12 및 13을 리턴합니다(2015년 9월 11일인 2일 전에 또는 그 이후에).
- createTime=<2d는 JOBINSTANCEID의 10 및 11을 리턴합니다(2015년 9월 11일인 2일 전에 또는 그 이전에).
- createTime=2015-11-08:2015-11-11은 JOBINSTANCEID의 11,12 및 13의 레코드를 리턴합니다.
- createTime=2015-11-10은 JOBINSTANCEID 12의 레코드를 리턴합니다.
- 샘플 요청:
https://localhost:9443/ibm/api/batch/v2/jobinstances?jobInstanceId=20:50 https://localhost:9443/ibm/api/batch/jobinstances?createTime=>2d https://localhost:9443/ibm/api/batch/v2/jobinstances?jobInstanceId=4,12,17&instanceState=COMPLETED https://localhost:9443/ibm/api/batch/v2/jobinstances?jobInstanceId=4500:4600&createTime=2015-11-27&instanceState=COMPLETED&exitStatus=*JOB*&page=0&pageSize=1000
GET /ibm/api/batch/v3/jobinstances/
GET /ibm/api/batch/v2/job instances/ URI의 모든 함수 외에도 이 URI는 다음 조회 매개변수를 통해 필터링되는 작업 인스턴스의 목록을 리턴합니다.
- lastUpdatedTime=[yyyy-MM-dd]: 지정된 날짜에 마지막으로 업데이트된 작업 인스턴스를 리턴합니다. 이 시간 값은 인스턴스 상태의 상태 전이 시 업데이트됩니다. 예를 들어, SUBMITTED에서 DISPATCHED로 업데이트됩니다.
- jobParameter.[paramName]=[paramValue]: 작업 매개변수로 제공된 이름:값 쌍이 있는 실행으로 작업 인스턴스를 리턴합니다. 예를 들어, jobParameter.jesJobName=myJobName입니다. 이 문자열 기준의 경우 문자열의 임의의 위치에 와일드카드(*) 연산자를 사용할 수 있습니다.
- sort=[string],[string]: 결과를 기준에 따라 정렬하기 위한 매개변수를 지정합니다. - 문자를 사용하여 매개변수 접두부를 지정하면 정렬이 내림차순으로 지정됩니다. 예를 들어, sort=submitter는 제출자별 결과를 오름차순으로 정렬합니다. sort=submitter,-lastUpdatedTime을 지정하면 먼저 제출자별 결과를 오름차순으로 정렬한 후 lastUpdatedTime별로 내림차순으로 정렬합니다.
GET /ibm/api/batch/v4/jobinstances/
GET /ibm/api/batch/v3/job instances/ URI의 모든 함수 외에도 이 URI는 다음 조회 매개변수를 통해 필터링되는 작업 인스턴스의 목록을 리턴합니다.
- submitter=[user]: 지정된 사용자가 제출한 모든 작업 인스턴스를 리턴합니다. 이 문자열 기준의 경우 문자열의 임의의 위치에 와일드카드(*) 연산자를 사용할 수 있습니다.
- appName=[name]: 지정된 애플리케이션 이름을 보유한 모든 작업 인스턴스를 리턴합니다. 이 이름은 단순 애플리케이션 이름 또는 전체 앱-모듈-컴포넌트 이름이 될 수 있습니다. 예를 들어 MyApp 또는 MyApp#MyApp.war을 검색하는 경우 애플리케이션 이름이 MyApp이고 모듈 이름이 MyApp.war인 작업 인스턴스를 리턴합니다. 이 문자열 기준의 경우 문자열의 임의의 위치에 와일드카드(*) 연산자를 사용할 수 있습니다.
- jobName=[name]: 지정된 작업 이름을 보유한 모든 작업 인스턴스를 리턴합니다. 이 문자열 기준의 경우 문자열의 임의의 위치에 와일드카드(*) 연산자를 사용할 수 있습니다.
- ignoreCase=true: 기본적으로 모든 텍스트 일치 항목에서는 대소문자를 구분합니다. 이 옵션을 지정하면 모든 텍스트 검색어에서 대소문자를 구분하지 않도록 변경합니다.
- lastUpdatedTime=[yyyy-MM-dd]:[yyyy-MM-dd]: 날짜 범위 사이에서(경계값 포함) 마지막으로 업데이트된 작업 인스턴스를 리턴합니다.
- lastUpdatedTime=>3d: 3일 전의 날짜에 또는 그 이후에 마지막으로 업데이트된 작업 인스턴스를 리턴합니다. 예를 들어 lastUpdatedTime은 3일 전 날짜의 시작보다 크거나 같습니다.
- lastUpdatedTime=<3d: 3일 전의 날짜에 또는 그 이전에 마지막으로 업데이트된 작업 인스턴스를 리턴합니다. 예를 들어 lastUpdatedTime은 3일 전 날짜의 종료보다 작거나 같습니다.
참고: appName, exitStatus, jobName 및 submitter 매개변수를 두 번 이상 적용할 수 있습니다. 결과에는 제공된 값 중 일치하는 모든 작업 인스턴스가 포함됩니다. 예를 들어 jobinstances?submitter=Alice&submitter=Bob을 지정하면 Alice OR Bob으로 제출된 모든 작업 인스턴스가 리턴됩니다.- GET /ibm/api/batch/jobinstances/job instance id
- 이 URI는 지정된 작업 인스턴스에 대한 자세한 정보(예: 지정된 작업 인스턴스와 연관된 모든 실행)를 리턴합니다. 결과는 최신 결과부터 가장 이전의 결과까지 순서대로 리턴됩니다. 최신 결과가 목록에서 첫 번째로 표시됩니다.
- 샘플 응답:
{ "jobName":"test_sleepyBatchlet", "instanceId":7, "appName":"SimpleBatchJob#SimpleBatchJob.war", "submitter":"bob", "batchStatus":"COMPLETED", "jobXMLName":"test_sleepyBatchlet", "instanceState":"COMPLETED", "_links":[ { "rel":"self", "href":"https://localhost:9443/ibm/api/batch/jobinstances/7" }, { "rel":"job logs", "href":"https://localhost:9443/ibm/api/batch/jobinstances/7/joblogs" }, { "rel":"job execution", "href":"https://localhost:9443/ibm/api/batch/jobinstances/7/jobexecutions/7" } ] }
- POST /ibm/api/batch/jobinstances/
- 새 작업을 제출(시작)하려면 이 URI를 사용하십시오. 다음 예는 WAR 모듈에 패키징된 작업을 제출하기 위한 요청 본문을 JSON 형식으로 보여줍니다.
{ "applicationName" : "SimpleBatchJob", "moduleName" : "SimpleBatchJob.war", "jobXMLName" : "test_batchlet_jsl", "jobParameters" : { "prop1" : "prop1value", "prop2" : "prop2value"} }
다음 예는 EJB 모듈에 패키징된 작업을 제출하기 위한 요청 본문을 JSON 형식으로 보여줍니다.{ "applicationName" : "SimpleBatchJob", "moduleName" : "SimpleBatchJobEJB.jar", "componentName" : "MyEJB", "jobXMLName" : "test_batchlet_jsl", "jobParameters" : { "prop1" : "prop1value", "prop2" : "prop2value"} }
applicationName은 일괄처리 애플리케이션을 식별합니다. 이 변수는 moduleName을 지정하지 않는 경우 필요합니다. 이 경우 applicationName은 moduleName에서 .war 또는 .jar 접미부를 잘라내고 moduleName에서 파생됩니다. 예를 들면, applicationName을 제공하지 않고 moduleName=SimpleBatchJob.war인 경우 applicationName의 기본값은 SimpleBatchJob입니다.
moduleName은 JSL과 같은 작업 아티팩트를 포함하는 일괄처리 애플리케이션 내의 모듈을 식별합니다. 작업은 모듈의 컴포넌트 컨텍스트에 따라 제출됩니다. moduleName은 applicationName을 지정하지 않는 경우 필요합니다. 이 경우 moduleName은 applicationName에 .war를 추가하여 applicationName에서 파생됩니다. 예를 들면, applicationName=SimpleBatchJob이고 moduleName을 제공하지 않는 경우, moduleName의 기본값은 SimpleBatchJob.war입니다.
componentName은 일괄처리 애플리케이션 EJB 모듈 내의 EJB 컴포넌트를 식별합니다. 이 변수를 지정하는 경우 작업은 EJB의 컴포넌트 컨텍스트에 따라 제출됩니다.참고: componentName은 EJB 모듈인 경우에만 필요합니다. WAR 모듈인 경우 componentName은 필요하지 않습니다.jobXMLName의 값을 입력해야 합니다. jobParameters의 값은 선택사항입니다.
- META-INF/일괄처리 작업 하의 일괄처리 애플리케이션 내에서 패키징된 JSL 작업 정의
사용에 대한 대안으로서, 사용자는 REST 작업 제출 요청의 일부로서 인라인으로 JSL을 전달할 수 있습니다.
인라인으로 제출된 JSL은 일괄처리 애플리케이션으로 패키징된 JSL을 항상 대체합니다. HTTP 요청의
일부로 JSL 인라인을 제출하기 위해 두 가지 방법을 사용할 수 있습니다.
- JSL을 작업 제출 요청의 JSON 특성으로서 포함합니다.
jobXML 특성을 JSON 오브젝트에 추가하고,
JSL 파일의 전체 컨텐츠를 특성 값으로서 JSON 문자열로 추가하십시오. 참고: JSON 구문 분석기에 의해 구문 분석될 수 있도록, XML 문자열을 적합하게 이스케이프 처리해야 합니다. 대부분의 JSON 라이브러리는 사용자 대신 이를 수행합니다.다음 예는 JSON에 의해 인라인으로 JSL이 전달되는 단일 파트 HTTP 요청을 사용하는 작업을 제출하기 위한 요청 본문을 보여줍니다.
{ "applicationName" : "SimpleBatchJob", "jobXMLName":"test_multiPartition_3Steps", "jobXML":"<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?> \r\n<job id=\"test_multiPartition_3Steps\" xmlns=\"http://xmlns.jcp.org/xml/ns/javaee\"r\n\tversion=\"1.0> \r\n\t<step id=\"step1"\" next=\"step2\"> \r\n\t\t<batchlet ref=\"simpleBatchlet\"/> \r\n\t\t<partition>\r\n\t\t\t<plan partitions=\"3\"/> \r\n\t\t</partition>\r\n\t</step> \r\n\t<step id=\"step2\" next=\"step3\"> \r\n\t\t<batchlet ref=\"simpleBatchlet\" /> \r\n\t\t<partition>\r\n\t\t\t<plan partitions=\"3\" /> \r\n\t\t</partition>\r\n\t</step>\r\n\t<step id=\"step3\"> \r\n\t\t<batchlet ref=\"simpleBatchlet\" />\r\n\t\t<partition> \r\n\t\t\t<plan partitions=\"3\"/> \r\n\t\t</partition>\r\n\t</step>\r\n</job>" }
참고: jobXML 필드는 JSON 구문 분석기에 의해 구문 분석되고 올바른 JSON 오브젝트로 마샬링되어야 합니다. 인라인 JSL의 작업 ID 정보가 작업 이름에 사용되므로, jobXMLName 필드는 선택사항입니다. - HTTP 멀티파트 양식을 사용하십시오. HTTP 멀티파트 양식을 사용하는 경우에는
JSON 작업 제출 데이터 및 XML 작업 정의가 HTTP 본문의 두 개의 별도 파트로서 제출되어야 합니다.
멀티파트 양식의 JSON 파트는 jobdata로 이름 지정되어야 하며,
양식의 XML 파트는 jsl로 이름 지정되어야 합니다.
멀티파트 양식을 사용하는 경우에는 XML을 JSON 문자열로 마샬링할 필요가 없습니다. 다음 예는 jsl 메시지 파트를 통해 JSL이 인라인으로 전달되는 멀티파트 HTTP 요청을 사용하는 작업을 제출하기 위한 HTTP 요청을 보여줍니다.
Content-Type: multipart/form-data;boundary=---------------------------49424d5f4a4241544348 -----------------------------49424d5f4a4241544348 Content-Disposition: form-data; name="jobdata" Content-Type: application/json; charset=UTF-8 { "applicationName" : "SimpleBatchJob", "moduleName" : "SimpleBatchJob.war", "jobXMLName" : "test_multiPartition" } -----------------------------49424d5f4a4241544348 Content-Disposition: form-data; name="jsl" Content-Type: application/xml; charset=UTF-8 <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <job id="test_multiPartition" xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="1.0"> <step id="step1"> <batchlet ref="simpleBatchlet" /> <partition> <plan partitions="3" /> </partition> </step></job> -----------------------------49424d5f4a4241544348--
참고: 인라인 JSL의 작업 ID 정보가 작업 이름에 사용되므로, jobXMLName 필드는 선택사항입니다.
- JSL을 작업 제출 요청의 JSON 특성으로서 포함합니다.
jobXML 특성을 JSON 오브젝트에 추가하고,
JSL 파일의 전체 컨텐츠를 특성 값으로서 JSON 문자열로 추가하십시오.
- 다음 샘플 응답은 완료된 작업 제출을 나타냅니다.
{ "jobName": "test_sleepyBatchlet", "instanceId": 10, "appName": "SimpleBatchJob#SimpleBatchJob.war", "submitter": "bob", "batchStatus": "STARTING", "jobXMLName": "test_sleepyBatchlet", "instanceState": "SUBMITTED", "_links": [ { "rel": "self", "href": "https://localhost:9443/ibm/api/batch/jobinstances/10" }, { "rel": "job logs", "href": "https://localhost:9443/ibm/api/batch/jobinstances/10/joblogs" } ] }
- PUT /ibm/api/batch/jobinstances/job instance id?action=stop
- 최신 작업이 실행 중인 경우 이 작업 인스턴스와 연관된 최신 작업 실행을 중지하려면 이 URI를 사용하십시오. 최신 작업이 실행 중이 아닌 경우 API는 오류를 리턴합니다.
- PUT /ibm/api/batch/jobinstances/job instance id?action=restart
- 최신 작업 실행이 STOPPED 또는 FAILED 상태인 경우에만 이 작업 인스턴스와 연관된 최신 작업 실행을 다시 시작하려면 이 URI를 사용하십시오. 작업 실행이 이 인스턴스와 연관되지 않거나 최신 작업 실행이 COMPLETED 상태인 경우 API는 오류를 리턴합니다.
- PUT /ibm/api/batch/jobinstances/job instance id?action=restart&reusePreviousParams=true
- 최신 작업을 다시 시작하고 이 작업 인스턴스와 연관된 이전 실행의 작업 매개변수를 다시 사용하려면 이 URI를 사용하십시오. 이전 실행은 STOPPED 또는 FAILED 상태여야 합니다.
작업 실행이 이 인스턴스와 연관되지 않거나
최신 작업 실행이 COMPLETED 상태인 경우 API는 오류를 리턴합니다.reusePreviousParams는 선택적 설정이라는 점을 참고하십시오.
기본 설정은 reusePreviousParams=false입니다.
참고: reusePreviousParams=true인 경우에는 현재 다시 시작 요청의 일부로서 제출된 작업 매개변수가 이전 작업 매개변수보다 우선순위를 갖습니다. 현재 매개변수는 작업 매개변수 키 이름이 같은 이전 매개변수를 대체합니다.
- DELETE /ibm/api/batch/jobinstances/job instance id
- 이 URI은 이 작업 인스턴스와 연관된 모든 데이터베이스 항목과 작업 로그를 제거합니다.
작업 인스턴스에 활성 작업 실행이 있는 경우
이 API는 오류를 리턴합니다. 작업 로그를 삭제할 때 오류가 발생하는 경우에는
작업 저장소 데이터베이스에서 작업 인스턴스 데이터를 삭제하려는 시도가 수행되지 않습니다. 조회 매개변수는 다음과 같습니다.
- purgeJobStoreOnly=true|false: purgeJobStoreOnly=true이면
이 작업 인스턴스와 연관된 작업 로그를 제거하려는 시도가 없습니다. 기본 설정은 purgeJobStoreOnly=false입니다. 작업 인스턴스에 활성 작업 실행이 있는 경우
이 API는 오류를 리턴합니다. 참고: 단일 제거 API를 사용할 때는 어떤 제거 응답 메시지도 리턴되지 않습니다.
- purgeJobStoreOnly=true|false: purgeJobStoreOnly=true이면
이 작업 인스턴스와 연관된 작업 로그를 제거하려는 시도가 없습니다. 기본 설정은 purgeJobStoreOnly=false입니다. 작업 인스턴스에 활성 작업 실행이 있는 경우
이 API는 오류를 리턴합니다.
- DELETE /ibm/api/batch/v2/jobinstances/
- 이 URI는 다음 제거 필터 매개변수에 의해 리턴된 작업 인스턴스와 연관된 모든 데이터베이스 항목 및 작업 로그를 제거합니다. 참고: GET 인터페이스를 사용하여 작업을 나열하고 제거하기 위한 DELETE 인터페이스를 수행하기 전에 제거를 위한 올바른 작업인지 확인하도록 권장합니다.
- page=[page number]: 리턴할 페이지(레코드의 서브세트)를 표시합니다. 기본값은 0입니다.
- pageSize=[number of records per page]: 페이지당 레코드 수를 표시합니다. 기본값은 50입니다.
- purgeJobStoreOnly=true|false: purgeJobStoreOnly=true일 때 이 작업 인스턴스와 연관된 작업 로그를 제거하는 시도가 이루어지지 않습니다. 기본 설정은 purgeJobStoreOnly=false입니다. 작업 인스턴스에 활성 작업 실행이 있는 경우 이 API는 오류를 리턴합니다.
- jobInstanceId=[instanceId]:[instanceId]: instanceId 범위 사이(경계값 포함)에 있는 작업 인스턴스를 제거합니다.
- jobInstanceId=>[instanceId]: 제공된 instanceId보다 크거나 같은 작업 인스턴스를 제거합니다.
- jobInstanceId=<[instanceId]: 제공된 instanceId보다 작거나 같은 작업 인스턴스를 제거합니다.
- jobinstanceId=[instanceId],[instanceId],[instanceId]: 지정된 작업 인스턴스를 제거합니다.
- createTime=[yyyy-MM-dd]:[yyy-MM-dd]: 날짜 범위 사이(경계값 포함)의 작업 인스턴스를 리턴합니다.
- createTime=[yyyy-MM-dd]: 제공된 날짜의 작업 인스턴스를 리턴합니다.
- createTime=>3d: 3일 전의 날짜에 또는 그 이후에 작성된 작업 인스턴스를 리턴합니다. 예를 들어, createTime은 3일 전 날짜의 시작보다 크거나 같습니다.
- createTime=<3d: 3일 전의 날짜에 또는 그 이전에 작성된 작업 인스턴스를 리턴합니다. 예를 들어, createTime은 3일 전 날짜의 종료보다 작거나 같습니다.
- instanceState=[state],[state]: 제공된 상태의 작업 인스턴스를 제거합니다. 유효한 인스턴스 상태는 SUBMITTED, JMS_QUEUED, JMS_CONSUMED, DISPATCHED, FAILED, STOPPED, COMPLETED 및 ABANDONED입니다.
- exitStatus=[string]: 종료 상태 문자열과 일치하는 작업 인스턴스를 리턴합니다. 이 문자열 기준의 경우 양쪽 끝에서 와일드카드(*) 연산자를 사용할 수 있습니다.
참고: 기본적으로, page 및 pageSize 매개변수가 지정되지 않으면 최대 50개의 레코드가 제거됩니다.참고: createTime을 포함하는 조회에서 서버 기본 시간대의 역할작업을 제출할 때 작업 인스턴스에 대한 createTime은 작업 저장소에 저장되며 UTC로 정규화됩니다. createTime=[yyyy-MM-dd] 또는 createTime=[yyyy-MM-dd]:[yyy-MM-dd]:에서와 같이 yyyy-MM-dd를 통해 날짜를 지정하는 경우, 작업 인스턴스 테이블 레코드의 createTime 값에 대해 일치시킬 수 있도록 yyyy-MM-dd 날짜 문자열을 UTC 시간의 특정 범위로 변환해야 합니다. 이를 수행하기 위해, 애플리케이션은 REST 요청을 처리하는 서버의 기본 시간대를 사용합니다. 일치 대상인 UTC 시간 범위로 날짜 문자열을 변환하기 위해 사용되는 시간대가 바로 이 서버의 시간대입니다.
다음 표는 조회 매개변수 jobInstanceId=10:13에 의해 리턴되는 데이터를 보여줍니다.
* 작업 저장소가 UTC 형식으로 createTime을 저장하므로, 표에 있는 데이터는 특정 서버(예: "server1")의 서버 기본 시간대를 사용하여 형식화된 createTime을 표시한다는 점을 이해하는 것이 중요합니다. ("server1"과는) 다른 기본 시간대의 두 번째 서버의 관점에서 유사한 표를 작성한 경우에는 대응되는 시간대 기반 차이가 있는 다른 CREATETIME 열 값 세트가 표시됩니다. 이는 다음 예의 데이터베이스에서 UTC createTime 값으로 yyyy-MM-dd 날짜 문자열 매개변수를 맵핑하는 데 사용되는 REST 요청을 처리 중인 서버의 기본 시간대입니다.JOBINSTANCEID CREATETIME(server1 시간대에서 *) INSTANCESTATE EXITSTATUS 10 11-05-2015.01:10:00 COMPLETED SUCCESS 11 11-08-2014.02:20:00 COMPLETED SUCCESS 12 11-10-2015.03:30:00 FAILED FAILURE 13 11-11-2015:04:40:00 COMPLETED SUCCESS 다음 명령은 실행 대상인 서버와는 무관하게 동일한 결과를 리턴합니다.- jobInstanceId=11:13은 JOBINSTANCEID의 11, 12 및 13을 리턴합니다.
- jobInstanceId=>12는 JOBINSTANCEID의 12 및 13을 리턴합니다.
- jobInstanceId=<12는 JOBINSTANCEID의 11 및 12를 리턴합니다.
- jobInstanceId=11,12는 JOBINSTANCEID의 11 및 12를 리턴합니다.
- instanceState=FAILED는 JOBINSTANCEID 12를 리턴합니다.
- exitStatus=SUCCESS는 JOBINSTANCEID의 10, 11 및 13을 리턴합니다.
다음 명령은 서로 다른 기본 시간대를 지닌 서버에 대해 서로 다른 결과를 리턴할 수 있습니다. 이 예에서, 이는 서버의 기본 시간대로 11-11-2015:07:00:00의 날짜 및 시간에 "server1"(이전 표를 채우기 위해 사용되는 동일한 서버)에 대해 발행됩니다.- createTime=>2d는 JOBINSTANCEID의 12 및 13을 리턴합니다(2015년 9월 11일인 2일 전에 또는 그 이후에).
- createTime=<2d는 JOBINSTANCEID의 10 및 11을 리턴합니다(2015년 9월 11일인 2일 전에 또는 그 이전에).
- createTime=2015-11-08:2015-11-11은 JOBINSTANCEID의 11,12 및 13의 레코드를 리턴합니다.
- createTime=2015-11-10은 JOBINSTANCEID 12의 레코드를 리턴합니다.
- 샘플 응답:
[{"instanceId":394,"purgeStatus":"COMPLETED","message":"Successful purge.","redirectUrl":""}, {"instanceId":395,"purgeStatus":"COMPLETED","message":"Successful purge.","redirectUrl":""}, {"instanceId":396,"purgeStatus":"COMPLETED","message":"Successful purge.","redirectUrl":""}, {"instanceId":397,"purgeStatus":"COMPLETED","message":"Successful purge.","redirectUrl":""}, {"instanceId":398,"purgeStatus":"COMPLETED","message":"Successful purge.","redirectUrl":""}]
- 다음 purgeStatus 값이 리턴될 수 있습니다.
- COMPLETED
- 작업 제거가 정상적으로 완료되었음을 표시합니다.
- FAILED
- 작업 제거에 실패했음을 표시합니다.
- STILL_ACTIVE
- 아직 활성 상태이므로 작업 제거에 실패했음을 표시합니다.
- JOBLOGS_ONLY
- 데이터베이스 제거에는 실패했지만 작업 로그는 성공적으로 제거되었음을 표시합니다.
- NOT_LOCAL
- 작업이 로컬이 아니므로 작업 제거에 실패했음을 표시합니다.
작업 실행
- GET /ibm/api/batch/jobexecutions/job execution id
- 이 URI는 지정된 작업 실행에 대한 자세한 정보를 리턴하며 연관된 단계 실행과 작업 로그에 대한 링크를 포함합니다.
- 샘플 요청:
https://localhost:9443/ibm/api/batch/jobexecutions/9
- 샘플 응답:
{ "jobName":"test_sleepyBatchlet", "executionId":9, "instanceId":9, "batchStatus":"COMPLETED", "exitStatus":"COMPLETED", "createTime":"2015/05/07 16:09:41.025 -0400", "endTime":"2015/05/07 16:09:52.127 -0400", "lastUpdatedTime":"2015/05/07 16:09:52.127 -0400", "startTime":"2015/05/07 16:09:41.327 -0400", "jobParameters":{ }, "restUrl":"https://localhost:9443/ibm/api/batch", "serverId":"localhost/C:/ibm/RAD_workspaces/Liberty7/build.image/wlp/usr/server1", "logpath":"C:\\ibm\\Liberty\\wlp\\usr\\servers\\server1\\logs\\joblogs\\test_sleepyBatchlet\\2015-05-07\\instance.9\\execution.9\\", "stepExecutions":[ { "stepExecutionId":9, "stepName":"step1", "batchStatus":"COMPLETED", "exitStatus":"SleepyBatchlet:i=10;stopRequested=false", "stepExecution":"https://localhost:9443/ibm/api/batch/jobexecutions/9/stepexecutions/step1" } ], "_links":[ { "rel":"self", "href":"https://localhost:9443/ibm/api/batch/jobexecutions/9" }, { "rel":"job instance", "href":"https://localhost:9443/ibm/api/batch/jobinstances/9" }, { "rel":"step executions", "href":"https://localhost:9443/ibm/api/batch/jobexecutions/9/stepexecutions" }, { "rel":"job logs", "href":"https://localhost:9443/ibm/api/batch/jobexecutions/9/joblogs" }, { "rel":"stop url", "href":"https://localhost:9443/ibm/api/batch/jobexecutions/9?action=stop" } ] }
- GET /ibm/api/batch/jobexecutions/job execution id/jobinstance
- 이 URI는 지정된 작업 실행과 관련된 작업 인스턴스에 대한 자세한 정보를 리턴합니다.
- GET /ibm/api/batch/jobinstances/job instance id/jobexecutions
- 이 URI는 지정된 작업 인스턴스와 관련된 작업 실행에 대한 자세한 정보를 리턴합니다. 여기에는 연관된 단계 실행 및 작업 로그에 대한 링크가 포함됩니다.
- GET /ibm/api/batch/jobinstances/job instance id/jobexecutions/job execution sequence number
- 이 URI는 지정된 작업 인스턴스 ID와 관련하여 지정된 작업 실행에 대한 자세한 정보를 리턴합니다.
여기에는 연관된 단계 실행 및 작업 로그에 대한 링크가 포함됩니다. 참고: 작업 실행 순서 번호는 지정된 작업 인스턴스와 관련된 0번째, 첫 번째 두 번째 등의 작업 실행을 의미합니다.
- PUT /ibm/api/batch/jobexecutions/job execution id?action=stop
- 지정된 실행 중인 작업 실행을 중지하려면 이 URI를 사용하십시오. 필수 매개변수는 action = stop, restart입니다.
- PUT /ibm/api/batch/jobexecutions/job execution id?action=restart
- 지정된 작업 실행을 다시 시작하려면 이 URI를 사용하십시오. 필수 매개변수는 action = stop, restart입니다.
단계 실행
- GET /ibm/api/batch/jobexecutions/job execution id/stepexecutions
- 이 URI는 지정된 작업 실행에 대해 모든 단계 실행 세부사항의 JSON 배열을 리턴합니다. 파티션된 단계가 작업에 포함된 경우 파티션 정보는 각 단계 내에 나열되어 리턴됩니다.
- 샘플 요청:
https://localhost:8020/ibm/api/batch/jobexecutions/40/stepexecutions
- 다음 샘플은 파티션된 단계에 대한 응답을 나타냅니다.
[ { "stepExecutionId":47, "executionId":39, "instanceId":35, "stepName":"step1", "batchStatus":"COMPLETED", "startTime":"2015/03/30 11:10:08.652 -0400", "endTime":"2015/03/30 11:10:09.817 -0400", "exitStatus":"COMPLETED", "metrics":{ "READ_COUNT":"0", "WRITE_COUNT":"0", "COMMIT_COUNT":"0", "ROLLBACK_COUNT":"0", "READ_SKIP_COUNT":"0", "PROCESS_SKIP_COUNT":"0", "FILTER_COUNT":"0", "WRITE_SKIP_COUNT":"0" }, "partitions":[ { "partitionNumber":0, "batchStatus":"COMPLETED", "startTime":"2015/03/30 11:10:09.579 -0400", "endTime":"2015/03/30 11:10:09.706 -0400", "exitStatus":"step1", "metrics":{ "READ_COUNT":"0", "WRITE_COUNT":"0", "COMMIT_COUNT":"0", "ROLLBACK_COUNT":"0", "READ_SKIP_COUNT":"0", "PROCESS_SKIP_COUNT":"0", "FILTER_COUNT":"0", "WRITE_SKIP_COUNT":"0" } }, { "partitionNumber":1, "batchStatus":"COMPLETED", "startTime":"2015/03/30 11:10:09.257 -0400", "endTime":"2015/03/30 11:10:09.302 -0400", "exitStatus":"step1", "metrics":{ "READ_COUNT":"0", "WRITE_COUNT":"0", "COMMIT_COUNT":"0", "ROLLBACK_COUNT":"0", "READ_SKIP_COUNT":"0", "PROCESS_SKIP_COUNT":"0", "FILTER_COUNT":"0", "WRITE_SKIP_COUNT":"0" } }, { "partitionNumber":2, "batchStatus":"COMPLETED", "startTime":"2015/03/30 11:10:09.469 -0400", "endTime":"2015/03/30 11:10:09.548 -0400", "exitStatus":"step1", "metrics":{ "READ_COUNT":"0", "WRITE_COUNT":"0", "COMMIT_COUNT":"0", "ROLLBACK_COUNT":"0", "READ_SKIP_COUNT":"0", "PROCESS_SKIP_COUNT":"0", "FILTER_COUNT":"0", "WRITE_SKIP_COUNT":"0" } } ] }, { "stepExecutionId":51, "executionId":39, "instanceId":35, "stepName":"step2", "batchStatus":"COMPLETED", "startTime":"2015/03/30 11:10:09.915 -0400", "endTime":"2015/03/30 11:10:10.648 -0400", "exitStatus":"COMPLETED", "metrics":{ "READ_COUNT":"0", "WRITE_COUNT":"0", "COMMIT_COUNT":"0", "ROLLBACK_COUNT":"0", "READ_SKIP_COUNT":"0", "PROCESS_SKIP_COUNT":"0", "FILTER_COUNT":"0", "WRITE_SKIP_COUNT":"0" }, "partitions":[ { "partitionNumber":0, "batchStatus":"COMPLETED", "startTime":"2015/03/30 11:10:10.324 -0400", "endTime":"2015/03/30 11:10:10.417 -0400", "exitStatus":"step2", "metrics":{ "READ_COUNT":"0", "WRITE_COUNT":"0", "COMMIT_COUNT":"0", "ROLLBACK_COUNT":"0", "READ_SKIP_COUNT":"0", "PROCESS_SKIP_COUNT":"0", "FILTER_COUNT":"0", "WRITE_SKIP_COUNT":"0" } }, { "partitionNumber":1, "batchStatus":"COMPLETED", "startTime":"2015/03/30 11:10:10.260 -0400", "endTime":"2015/03/30 11:10:10.347 -0400", "exitStatus":"step2", "metrics":{ "READ_COUNT":"0", "WRITE_COUNT":"0", "COMMIT_COUNT":"0", "ROLLBACK_COUNT":"0", "READ_SKIP_COUNT":"0", "PROCESS_SKIP_COUNT":"0", "FILTER_COUNT":"0", "WRITE_SKIP_COUNT":"0" } }, { "partitionNumber":2, "batchStatus":"COMPLETED", "startTime":"2015/03/30 11:10:10.507 -0400", "endTime":"2015/03/30 11:10:10.557 -0400", "exitStatus":"step2", "metrics":{ "READ_COUNT":"0", "WRITE_COUNT":"0", "COMMIT_COUNT":"0", "ROLLBACK_COUNT":"0", "READ_SKIP_COUNT":"0", "PROCESS_SKIP_COUNT":"0", "FILTER_COUNT":"0", "WRITE_SKIP_COUNT":"0" } }, { "_links":[ { "rel":"job execution", "href":"https://localhost:9443/ibm/api/batch/jobexecutions/9" }, { "rel":"job instance", "href":"https://localhost:9443/ibm/api/batch/jobinstances/9" } ] } ]
- GET /ibm/api/batch/jobexecutions/job execution id/stepexecutions/step name
- 이 URI는 지정된 작업 실행에 대한 단계 실행 세부사항과 단계 이름을 포함한 JSON 배열을 리턴합니다.
- GET /ibm/api/batch/jobinstances/job instance id/jobexecutions/job execution sequence number/stepexecutions/step name
- 이 URI는 지정된 작업 인스턴스에 대한 단계 실행 세부사항, 작업 실행 및 단계 이름을 포함한 JSON 배열을 리턴합니다.
- GET /ibm/api/batch/stepexecutions/step execution id
- 이 URI는 지정된 단계 실행에 대해 단계 실행 세부사항을 포함한 JSON 배열을 리턴합니다.
작업 로그
- GET /ibm/api/batch/jobinstances/job instance id/joblogs
- 이 URI는 지정된 작업 인스턴스의 모든 작업 로그 파트에 대한 REST 링크가 포함된 JSON 배열을 리턴합니다.
- GET /ibm/api/batch/jobexecutions/job execution id/joblogs
- 이 URI는 지정된 작업 실행의 모든 작업 로그 파트에 대한 REST 링크가 포함된 JSON 배열을 리턴합니다.중요사항: 다음 예는 REST 링크의 형식을 보여줍니다.작업 실행에 다음과 같은 작업 로그 파트가 있는 경우
해당하는 REST 링크는 다음과 같습니다.joblogs/instance.inst-id/execution.exec-id/part.1.log joblogs/instance.inst-id/execution.exec-id/part.2.log joblogs/instance.inst-id/execution.exec-id/step.step-name/partition.0/part.1.log joblogs/instance.inst-id/execution.exec-id/step.step-name/partition.1/part.1.log
/ibm/api/batch/jobexecutionsexec-id/joblogs?part=part.1.log /ibm/api/batch/jobexecutionsexec-id/joblogs?part=part.2.log /ibm/api/batch/jobexecutionsexec-id/joblogs?part=step.step-name/partition.0/part.1.log /ibm/api/batch/jobexecutionsexec-id/joblogs?part=step.step-name/partition.1/part.1.log
- 선택적 매개변수는 다음과 같습니다.
- type = text
- 텍스트는 일반 텍스트로서 모든 작업 로그를 리턴합니다. 모든 작업 로그 파트는 함께 수집됩니다. 헤더 레코드와 푸터 레코드를 구분하는 파트는 스트림에 삽입되어 작업 로그 파트가 함께 수집될 때 다른 파트를 구분합니다.
- type = zip
- Zip은 지정된 작업 인스턴스 또는 작업 실행에 대한 모든 작업 로그를 압축 파일로 리턴합니다. 작업 로그의 디렉토리 구조는 압축 파일로 유지됩니다.
- GET /ibm/api/batch/jobinstances/job instance id/joblogs?type=text|zip
- GET /ibm/api/batch/jobexecutions/job execution id/joblogs?type=text|zip
- type 매개변수가 지정된 이 두 URI의 동작은 값에 따라 다릅니다.
- type = text
- 텍스트는 일반 텍스트로서 모든 작업 로그를 리턴합니다. 모든 작업 로그 파트는 함께 수집됩니다. 헤더 레코드와 푸터 레코드를 구분하는 파트는 스트림에 삽입되어 작업 로그 파트가 함께 수집될 때 다른 파트를 구분합니다.
- type = zip
Zip은 지정된 작업 인스턴스 또는 작업 실행에 대한 모든 작업 로그를 압축 파일로 리턴합니다. 작업 로그의 디렉토리 구조는 압축 파일로 유지됩니다.
- GET /ibm/api/batch/jobexecutions/job execution id/joblogs?part=path to part&type=text|zip
- part 매개변수가 지정된 경우 이 URI는 작업 로그 파트를 일반 텍스트(type=text) 또는 압축 파일(type=zip)로 리턴합니다. 기본 설정은 type=text입니다.
HTTP 리턴 코드
- HTTP 200 OK
- HTTP 201 자원을 새로 작성했습니다.
- HTTP 202 요청을 수락했지만, 처리가 완료되지 않았습니다.
- HTTP 400 매개변수가 올바르지 않은 잘못된 요청입니다. 자세한 내용은 리턴된 메시지를 참조하십시오.
- HTTP 401 이 자원에 액세스할 수 있는 권한이 없습니다.
- HTTP 403 인증에 실패했습니다.
- HTTP 404 요청된 자원을 찾을 수 없거나 자원이 존재하지 않습니다.
- HTTP 409 요청이 자원의 현재 상태와 충돌합니다. 자세한 내용은 리턴된 메시지를 참조하십시오.
- HTTP 500 내부 서버 오류입니다.
분산 서버 일괄처리 환경에서의 STOP 요청
일괄처리 REST API로 전송되는 중지 요청은 작업이 실행 중인 실행기로 직접 전송되어야 합니다. 작업이 실행되고 있지 않은 디스패처 또는 실행기로 중지 요청이 전송되면 HTTP 302 경로 재지정 응답 메시지에 의해 요청이 올바른 실행기로 경로 재지정됩니다. HTTP 302 경로 재지정 응답의 위치 필드는 중지 요청에 사용할 올바른 URL을 표시합니다.