| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Expansion of WSDL |
« View previous topic :: View next topic » |
| Author |
Message
|
| asrajesh |
 Posted: Wed Feb 13, 2013 6:06 am Post subject: Expansion of WSDL |
 |
|
Novice
Joined: 19 Jan 2013
Posts: 20
|
Hi,
Good day.
We are using WMB 7.0. We are in the process of migrating from existing middleware to message broker in phased approach. Currently, we have deployed some services in production and one client(CLNT-A) started consuming those services.
Now, one more client(CLNT-B) came to use MB. they have requirement to add one more flag to be introduced in the response message of one of the existing service.
If we add that flag(even make it as OPTIONAL in WSDL) in that service, the existing client(CLNT-A) who is also using the same service gets impacted because of WSDL mismatch.
Is there any way to expand the service without the impact of existing clients.
Thanks
Regards
S. Rajesh |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Wed Feb 13, 2013 6:10 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Yes, add the flag at the end of the XSD, not in the middle. Then both clients can successfully use the service.
Note this issue has nothing to do with message broker and everything to do with managing WSDLs and service versions. You need a professional XML/Web Service developer on your team. Maintaining a library of good XSDs and WSDLs is not as easy as some people think.
A couple of tips for writing XSDs and using them in WMB:
- Don't use numeric ENUMs (ie. 1000004 means home phone). Use human-readable ENUMs (ie. HOME_PHONE means home phone) so if you are awake at 2 in the morning trying to solve a production problem, you can easily make out what goes with what.
- Version your Web Service; just like you would version source code. Client A should call V1.0 and Client B should call V1.1.
- Help your customers understand the path for migration. Over time, you want to move your clients up the version tree to get the benefits of a more refined web service.
- You can write logic in your SoapReply handler that includes only the tags you want. (ie. when the caller is using V1.0 web service, return the soap reply without the additional tag.)
- Always use namespaces. Don't use tags without namespaces.
- Your SOAP message flow should have exactly and only two levels. On the top level, "main flow level", you should have the SOAPInput, SOAPReply, and error handler. On the child level, "subflow level", you should have the logic that services the request and creates the SoapReply message data in the Environment tree. The main flow can include as many subflows as needed, daisy-chained together. Subflows should not include other subflows. When all daisy-chained subflows have executed, copy the relevant parts of the SoapReply data into a bonafide OutputRoot.SOAP message just before your SoapReply node in the main flow.
- For each subflow, start with a FlowOrder node. First leg feeds the logic path, and the second leg feeds the Output node. This lets you daisy chain subflows together in the main flow. Save the results of your logic path into the Environment tree so that downstream subflows can use them.
- If you are going to return a SoapFault, make sure you set the HTTPStatus code to something other than 200 (ie. 500, 501, 502, etc).
| Code: |
| SET OutputLocalEnvironment.Destination.SOAP.Reply.Transport.HTTP.ReplyStatusCode = 500; |
- Make liberal use of Trace nodes:
| lancelotlinc wrote: |
| kash3338 wrote: |
| lancelotlinc wrote: |
| The interactive debugger is a poor choice here. Try Trace nodes. |
Accepted, trace nodes are a good choice, but why do you say interactive debugger as a poor choice? Any specific reason? |
Because its hard to keep track of where you are in the flow, and once you pass the problem area in the interactive state, you have to start all over again. Using a method of debugging in which the interested information is stored is much preferable because the timing is maintained. Some WMB facilities depend on timing. Getting in the habit of using Trace nodes for design and debugging which will save you a boat load of time trying to catch hard to find issues.
All these things in addition to what Vitor said, which was quite visionary.
Some basic rules for Trace nodes:
1. Put a trace node between each major node in your flow.
2. Make sure all terminals are attached to a unique Trace node.
3. Use Throw nodes if needed.
4. Don't put more than one input wire to any Trace node.
5. Make sure each unique Trace node writes to a unique file on disk.
6. Here is an example pattern:
| Code: |
Root:
${Root}
===
LocalEnvironment:
${LocalEnvironment}
===
Environment:
${Environment}
===
ExceptionList:
${ExceptionList}
===
${CURRENT_TIMESTAMP}
======================= |
7. Get good at reading trace files.
8. If your trace files contain PCI or ePHI data, turn them off in Production through the mqsichangetrace command. Trace nodes that are off in Production consume virtually no resources.
9. A good naming convention to use for Trace file names is <flow_name>_<trace node name>.txt
10. A good naming convention for Trace nodes is 1, 1ERR, 2, 3 (for SoapRequest Out terminal), 3FAULT (for SoapRequest Fault terminal) etc. Trace '1' would be the first node after the FlowOrder leg 1 in your subflows. Trace '2' would be immediately after your Compute node (so you can see what the package is you are sending downstream through the SoapRequest). 1ERR hangs off the FlowOrder Failure terminal. Use a throw node there after the Trace node if needed.
|
- Measure latency in your subflows:
| Code: |
SET Environment.Variables.XMLNSC.{ReplyId}.<flowname>.StartTime = CURRENT_GMTTIMESTAMP;
...
SET Environment.Variables.XMLNSC.{ReplyId}.<flowname>.EndTime = CURRENT_GMTTIMESTAMP;
SET Environment.Variables.XMLNSC.{ReplyId}.<flowname>.ElapsedTime = ( CAST ( Environment.Variables.XMLNSC.{ReplyId}.<flowname>.EndTime AS TIME ) - CAST ( Environment.Variables.XMLNSC.{ReplyId}.<flowname>.StartTime AS TIME )) SECOND; |
- Store latency values in a database (via Web Service) call after you hit the SoapReply node. Have a database trigger sit on the column that holds the elapsed time. If the elapsed time exceeds a threshold (perhaps seven seconds), send an email out to sys admins. At the end of each business day, run a database script that consolidates the individual metrics into a summary format and email that out to relevant parties. Address any service level shortfalls with your downstream providers each day.
- Interactions with databases should be through a web service or solidDb. WMB V7/V8 database operations do not scale well due to the way the product handles database connection pool. :rfe: has been submitted, but so far the powers that be don't grant that :rfe: much traction. If you have three db conx in a msg flow and you increment the additional instances to ten, you just increased your connection pool usage to 30. Increment the additional instance to 100, and you just exhausted your connection pool. Thats why you should not make database calls directly from Soap message flows because you then cannot scale your Soap message flows up to the number that is needed. Create a web service that serves your database requests, and interact with these web services for all your Soap message flows. In this manner, you can scale all the way up to handle ten thousand Soap transactions per second.
- Use solidDb or MbCache to store transactional history over time. Write a command line utility or a utility message flow that can read this history and report.
- Use log4j from ESQL + other Compute nodes to report various decisions the logic makes in summary form with no PCI or ePHI data in the output. This is handy in Production when your Trace nodes are turned off. Use DailyRollingFileAppender of log4j so that your transactional summary log can contain one day's worth of data and gets rolled over every night. Put log4j.properties file in /var/mqsi/common/wsrr directory.
- Never use mqm as the Broker service Id. Always sudo into the Broker service Id before issuing any mqsi commands. http://www.mqseries.net/phpBB2/viewtopic.php?t=61512
- If you are interacting with a CICS bridge in your Soap message flow, be sure to increase the CICS buffer to something more than 32k.
- If you interface with a global customer management solution like MDM, be sure to generate the MDM classes WITH package names (requires an extra tick on the wizard dialog). Generating MDM server objects with package names means the resulting XSDs will come with namespaces. Failing to do so means the XSDs will contain all global variable declarations and this prevents you from using them directly in a message set definition since the global variable names will collide.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| asrajesh |
| Posted: Thu Feb 14, 2013 4:03 am Post subject: |
|
|
Novice
Joined: 19 Jan 2013
Posts: 20
|
Thank you very much for your valuable tips. Really, this would help us..
For this issue, we have tried the versioning and it worked fine.. Thanks a lot
Regards
S. Rajesh |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
