| Author |
Message
|
| catshout |
 Posted: Wed Dec 07, 2016 10:20 am Post subject: Bar file deployment against IIBv10 REST API (apiv1) |
 |
|
Acolyte
Joined: 15 May 2012
Posts: 57
|
Dear community,
we're trying to deploy a pre-created bar file against the IIBv10 REST API (apiv1) as documented here http://www.ibm.com/support/knowledgecenter/en/SSMKHH_10.0.0/com.ibm.etools.mft.restapi.doc/index.html
I was executing the following commands
| Code: |
/usr/bin/curl http://10.10.15.121:4414/apiv1/bar/readBar -X POST -v \
-c /var/jenkins/workspace/Runtime_Deploy_Entwicklung/IIBDeploy/Base/cookies.CTLGLO001.bar \
-F 'escapedBarFileName="CTLGLO001.bar"' \
-F 'barFile=@"/var/jenkins/workspace/Runtime_Deploy_Entwicklung/IIBDeploy/Base/CTLGLO001.bar"' |
| Code: |
/usr/bin/curl http://10.10.15.121:4414/apiv1/bar/readOverrides -X POST -v \
-b /var/jenkins/workspace/Runtime_Deploy_Entwicklung/IIBDeploy/Base/cookies.CTLGLO001.bar \
-F 'escapedOverridesFileName="dev.properties"' \
-F 'overridesFile=@"/var/jenkins/workspace/Runtime_Deploy_Entwicklung/IIBDeploy/Base/CTLGLO001/dev.properties"' |
| Code: |
/usr/bin/curl http://10.10.15.121:4414/apiv1/executiongroups/API_TEST_DEV/deploy -X POST -v \
-b /var/jenkins/workspace/Runtime_Deploy_Entwicklung/IIBDeploy/Base/cookies.CTLGLO001.bar \
-H 'Content-Type:application/x-www-form-urlencoded' \
-d '{"filename":"CTLGLO001.bar", "overridesfilename":"dev.properties"}' |
The 1st command returned a HTTP 200 and as response the bar file properties, formatted in JSON. The 2nd command returned a HTTP 200 and the override file content, formatted in JSON.
The 3rd command returned a HTTP 204, nothing more. Seems to be ok, but nothing has been deployed.
I was trying and debug the deploy steps with the Firefox console against the IIB Web UI to check the approach. In this case the deployment has been successful. I checked the parameters and headers, seem to be the same as with curl.
Does anyone have any experience with this kind of deployment yet and could give me any hint a) what might be wrong here or b) where to find more information about the deployment process (the IIB10 log says nothing in this case)?
Many thanks in advance
- Gerald |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Dec 07, 2016 11:30 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
This is what I *think*... I haven't tried it or examined it in detail.
The 204 indicates that broker has accepted the bar file for deploy.
That doesn't mean that the deploy has completed.
You could probably loop over a GET call to the EG to find out if it's deployed successfully - or hopefully something smarter than that.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| catshout |
| Posted: Wed Dec 07, 2016 11:48 am Post subject: |
|
|
Acolyte
Joined: 15 May 2012
Posts: 57
|
Tested some syntax modifications, by now this worked ..
| Code: |
/usr/bin/curl http://10.10.15.121:4414/apiv1/bar/readBar -X POST -v \
-c /var/jenkins/workspace/Runtime_Deploy_Entwicklung/IIBDeploy/Base/cookies.CTLGLO001.bar \
-F escapedBarFileName=CTLGLO001.bar \
-F barFile=@"/var/jenkins/workspace/Runtime_Deploy_Entwicklung/IIBDeploy/Base/CTLGLO001.bar" |
| Code: |
/usr/bin/curl http://10.10.15.121:4414/apiv1/bar/readOverrides -X POST -v \
-b /var/jenkins/workspace/Runtime_Deploy_Entwicklung/IIBDeploy/Base/cookies.CTLGLO001.bar \
-F escapedOverridesFileName="dev.properties" \
-F overridesFile=@"/var/jenkins/workspace/Runtime_Deploy_Entwicklung/IIBDeploy/Base/CTLGLO001/dev.properties" |
| Code: |
/usr/bin/curl http://10.10.15.121:4414/apiv1/executiongroups/API_TEST_DEV/deploy -X POST -v \
-b /var/jenkins/workspace/Runtime_Deploy_Entwicklung/IIBDeploy/Base/cookies.CTLGLO001.bar \
-H Content-Type:application/x-www-form-urlencoded \
-d {"filename":"CTLGLO001.bar", "overridesfilename":"dev.properties"} |
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Dec 07, 2016 11:53 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| catshout wrote: |
| by now this worked .. |
Worked how? all three gave a 200?
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| catshout |
| Posted: Thu Dec 08, 2016 12:58 am Post subject: |
|
|
Acolyte
Joined: 15 May 2012
Posts: 57
|
The 3rd gives a HTTP 204 in any case. This even if there is some typo and therefore nothing has been deployed.
Finally you need to check the successful deployment with this command
| Code: |
| /usr/bin/curl http://10.10.15.121:4414/apiv1/executiongroups/API_TEST_DEV/applications/CTLGLO001 -v |
This gives follwowing results
HTTP 200 Application is deployed
HTTP 404 Application does not exist (and have not been deployed so far)
In the succesful case the return of the command above is
| Code: |
| <?xml version="1.0" encoding="UTF-8" standalone="yes"?><application type="application" isRunning="true" runMode="running" startMode="Maintained" uri="/apiv1/executiongroups/API_TEST_DEV/applications/CTLGLO001" propertiesUri="/apiv1/executiongroups/API_TEST_DEV/applications/CTLGLO001/properties" uuid="6246cb79-0184-4216-933b-732fd7e42fe8" name="CTLGLO001"><libraries type="libraries" uri="/apiv1/executiongroups/API_TEST_DEV/applications/CTLGLO001/libraries" hasChildren="false" internal="false"/><messageFlows type="messageFlows" uri="/apiv1/executiongroups/API_TEST_DEV/applications/CTLGLO001/messageflows" hasChildren="true" internal="false"/><subFlows type="subFlows" uri="/apiv1/executiongroups/API_TEST_DEV/applications/CTLGLO001/subflows" hasChildren="false" internal="false"/><resources type="resources" uri="/apiv1/executiongroups/API_TEST_DEV/applications/CTLGLO001/resources" hasChildren="true" internal="false"/><references type="references" uri="/apiv1/executiongroups/API_TEST_DEV/applications/CTLGLO001/references" hasChildren="false" internal="false"/></application> |
No JSON in this case, still XML. One needs to valide further whether the application is running or not.
IMHO there's some room for improvement. I'd expect a HTTP 204 only in the case of a succesful deployment. Better a HTTP 200 with some state information. In the case that nothing has been deployed I'd expect a HTTP 500.
Best
- Gerald |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Dec 08, 2016 5:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
A successful deployment could take quite a while. It's very likely that your HTTP session would time out before that. So returning a 204 is a reasonable and better response than waiting for the successful deploy.
You then go back and check periodically to make sure the deploy has been completed.
Whether or not the set of flows/applications/services in a bar file have started is again subject to a timeout. If you check every 10 seconds for 2 minutes, and the flow hasn't started, does that mean it won't start in the next 10 seconds?
You have to decide the timeout interval and the frequency of checks yourself.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| catshout |
| Posted: Thu Dec 08, 2016 6:50 am Post subject: |
|
|
Acolyte
Joined: 15 May 2012
Posts: 57
|
The deployment time(out) is indeed a valid issue.
My point is that even in the case that none of the provided ressources (referenced by name in the HTTP request body) are exist (e.g. due to a typo) a HTTP 204 is being returned. At least this circumstance should provide some kind of error response. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Dec 08, 2016 6:57 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| catshout wrote: |
The deployment time(out) is indeed a valid issue.
My point is that even in the case that none of the provided ressources (referenced by name in the HTTP request body) are exist (e.g. due to a typo) a HTTP 204 is being returned. At least this circumstance should provide some kind of error response. |
Why? It does not provide one today.
The deployment messages that your broker proxy listens for will provide that information.
So if you got returned some kind of handle to check for deployment messages after the deployment attempt, that would be o.k.
This means that you should get a 200 with the handle to check with ...
or even a 204 and just check in general for the broker log message... 
_________________
MQ & Broker admin
Last edited by fjb_saper on Thu Dec 08, 2016 7:15 am; edited 1 time in total |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Dec 08, 2016 6:59 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| catshout wrote: |
The deployment time(out) is indeed a valid issue.
My point is that even in the case that none of the provided ressources (referenced by name in the HTTP request body) are exist (e.g. due to a typo) a HTTP 204 is being returned. At least this circumstance should provide some kind of error response. |
You mean the files referenced by the -b and -d parameters? Again, you're not actually sending the files in the request. You're just sending the names of the files.
The broker won't know that the files exist until it tries to use them.
Granted, the deploy call *could* verify that the files exist and return an error. But that's an RFE/PMR issue...
Also, not sure which HTTP Return code that would match to...
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| catshout |
| Posted: Thu Dec 08, 2016 7:51 am Post subject: |
|
|
Acolyte
Joined: 15 May 2012
Posts: 57
|
When I look at the IIB Web UI that is leveraging the REST API as well (checked in the Firefox debug window) there's a return for the succesful/non-succesful deployment.
This follows probably the async approach you mentioned, fjb_saper. Assuming there's a callback handler in place that is getting probably the deployment information from server after some time.
mqjeff, I'm going to think to raise a PMR/RFE for that part you mentioned. I'd expect a HTTP 500 with some error message in body if the files don't exist. But that might be part of the development design.
Both, thanks for sharing your thoughts and provide some more insights to this part of IIB. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Dec 08, 2016 7:54 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| catshout wrote: |
| mqjeff, I'm going to think to raise a PMR/RFE for that part you mentioned. I'd expect a HTTP 500 with some error message in body if the files don't exist. But that might be part of the development design. |
A 500 means that the server itself had an error...
A 400 might be a better fit, with a response message indicating what file doesn't exist, or can't be read.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| catshout |
| Posted: Thu Dec 08, 2016 8:02 am Post subject: |
|
|
Acolyte
Joined: 15 May 2012
Posts: 57
|
| Quote: |
A 500 means that the server itself had an error...
A 400 might be a better fit, with a response message indicating what file doesn't exist, or can't be read. |
Hm, HTTP 400 means that the request was malformed. In other words, the data stream sent by the client to the server didn't follow the rules. That's not the case in my mind as the syntax and the request body is well formed.
But anyway, finally this might be a design decision of the development team (if they wanna go to change the behaviour). |
|
| Back to top |
|
|
|
|
