I have a doc with xml dateTime constraint on a field.
I have a flow that takes an object (java.util.Date).
There must be an easy way to convert from one to another?
xml date time format uses ‘T’ delimiter. Can you tell what type of format you desire in XML?
[url]XML Schema Part 2: Datatypes Second Edition
That is the format of my source data. i.e. it comes from an xml document that uses an xsd schema. Yes it includes a ‘T’. webMethods even knows about this format as it allows you to provide it as a ‘constraint’ on a document definition.
I simply want to convert this into a java.util.Date object.
Apparently this is rocket science when using the “power” of Java + webMethods!!
Assuming you know how to do a Java service:
DatatypeFactory dataFactory = DatatypeFactory.newInstance();
to convert from string to java.util.Date:
Date dt = dataFactory.newXMLGregorianCalendar(xsdDateString).toGregorianCalendar().getTime();
to convert Date to string:
GregorianCalendar cal = new GregorianCalendar();
cal.setTime(data);
String s = dataFactory.newXMLGregorianCalendar(cal).toString();
Thanks monty.
It still amazes me how ill equiped webMethods is for dealing with the web. Kinda ironic considering its name!
Yeah well, to say it handles XML is a stretch in my book. They don’t even supply conversion functions for Date, Times, ints, etc. And the .Net support (after they get the bugs fixed) is way better than the Java support. It simply amazes me how they do not realize what a superb INTEGRATION tool IS is. And yet they don’t even appear to have tested the dotnet support, and jcode is a joke. I have over 20 SR’s reported on 7.1 and the fixes are slowly coming in.
And everyone tells me, ‘we don’t have any customers doing that’.
Anyway, good luck with the Java services, just becareful of the 64k limit on class size and the fact that jcode can only handle 100 or so java files at a time. Don’t even get me started on MaxPermGenSize.
]Monty[
What would you add to shore up the XML support?
I assume that by “conversion for Date, Times, ints, etc.” you mean converting back and forth between strings and Java types/objects. Do you do that a lot in your integrations? Generally, I find it advantageous to keep things as strings. Rarely do I convert things to objects or native types.
You ran into the 64k class size limit? Odd that there is that much Java coded needed. And that you bumped into a number of files limitation with jcode. Why are you doing so much Java?
I’ve been lucky enough to have avoided the need to do any .Net stuff within IS. Flat files or XML/SOAP over FTP and HTTP have been sufficient (preferred, actually).
That seems to be a pretty broad generalization–given the data point that IS doesn’t automatically convert a string to a Date, coming to the conclusion that IS is ill equipped to deal with the web is tad extreme I think.
[The specific post I was responding to, which complained about the quality of the wM forums/communities, appears to have been deleted.]
Wow. You do realize you’ve posted that in the middle of the leading wM community?
I’m sure you have other examples of where the communities haven’t met your expectations. For this thread, it took a week to get a decent answer but sometimes that’s how it goes with volunteer forums on basic questions. If Monty’s suggestion doesn’t work out (DatatypeFactory is from Java 5, which isn’t supported by 6.5 IIRC, and may not be supported by 7.x), please post again. The solution for the W3C timestamp string to a Date is trivial.
Those of us who have been working with IS, XML and “the Web” for 7+ years now don’t seem to have the same problems as you are experiencing.
The lack of a simple tool for mapping XML schema dateTimes is rooted in the differences between how java deals with timezone offsets and how oddly W3C defines dateTime. Once you understand those differences, creating a very small java service to handle that is extremely simple.
Other than for one client who wanted to use IS java services to consume EJB methods via RMIIOP, I have never seen a need to create java services that came anywhere close to the 64K limit for classes. If you’re doing that, chances are you’re not using the tool as it was intended to be used.
Every major new release of any major commercial or open source product has tons of bugs these days. That’s why I have advised my clients on IS 6.5 to hold off on 7.1 for at least six months. I would say the same for major new releases of app servers, databases, SOA governance tools, development languages, etc.
My current project is using SpringWS and our team has already logged several bugs and suggested fixes. That doesn’t mean I’m going to throw out the baby with the bathwater and go back to Axis.
M
Yeah, I deleted that post due to its profanity. I took the criticism of WM “forums and communities” as directed at Advantage, but perhaps incorrectly so.
Hey, its just technology. My son’s college was hit by a tornado tonight. Compared to his being safe, a little offbase criticism is easy to take in stride.
Turns out I didn’t recall correctly. Java 1.5 is supported by IS 6.5 SP2.
reamon - My view of IS is that it is an INTEGRATION server i.e. it is a great tool to service enable legacy apps. In my scenario, I have 500 or so CICS transactions I want to get on the bus. The nice thing about these is that they have a defined input and output ‘documents’. We also have an existing set of Java classes that basically represent each of these one-for-one, so I wrote a program to reflect on these Java classes and generate IS Java service code to ‘glue’ them into IS. Now we are writing nice services to expose these in a more course grained way. The problems with this approach have been: 1) jcode really can’t handle large number of java files, 2) the default IS JVM setup can’t handle that many Java services, and 3) if you put all of these into one ‘folder’ (which is actually a Java class) you will run into the 64K class size limit.
mcarlson - I say IS doesn’t support XML for practical reasons, once you start importing xsd for document creation, you come across many implementation problems, most notably the data type conversion problem. And why the weird-o names? could we please just use the ones in the document? And maybe directly support namespaces, instead of the xxx: thing?
By implementing everything in the pipeline as a string, you basically have a type-less environment, something XML is definitely not. The webMethods approach to data types is that they are strings that are constrained to a certain format, where in xml they truely are those data types. A subtle but important difference. One could ask the question why the pipeline isn’t natively XML or a DOM. But it isn’t. It is a recursive hashtable of hashtables, with string keys and string values. For that reason I say its XML support is minimum at best. Yes you can get XML into it, yes you can get XML out of it (one does wonder why their aren’t single services to do this serialization/deserialization, but I digress). The pipeline doesn’t support namespaces, or choices, or any.
Oh and thanks for not trying 7.1 so that I have to do all the QA myself. 
By the way, 7.1, once the bugs are all fixed, has fanstastic .Net and WebService support, even supporting WS-Security. It will be much easier to do Web Service consumption and exposition (when I get all the bugs fixed). 7.1.1 also will have great WSDL first (contract first) support.
]Monty[
Preaching to the choir my friend.
This is where you and I would differ on implementation. I probably would’ve tossed the Java classes and used only IS doc types.
I’ve mentioned this in many of my posts throughout the years–IS is not a Java app server like WS or WLS. The main language of IS is FLOW, not Java. The amount of Java in your integrations should be minimal, mostly narrowly focused utilities.
Indeed. I assume you have been forced to split them up.
By weird-o names, do you mean the namespace prefixes? The field names are retained. Namespaces are directly supported and allow for the namespace prefix to vary at runtime, per spec. Client A can use abc as the prefix and client B can use xyz–and your IS stuff can use foo and process docs from A and B without issue, as long as everyone uses the same namespace URI.
I’m splitting hairs a bit, but XML is typeless. XSD, which came well after XML hit the scene, applies type information, which is indicated in XML using attributes. XML without XSD is nothing but strings.
It’s been my experience that strong typing in the integration layer is usually undesirable. It is usually unnecessary. The vast majority of work in integrations has nothing to do with manipulating the data but simply moving it around. Thus, the integration doesn’t care what the data is, just the structure–e.g. field X in doc A moves to field a/b/c in doc B.
While there is sometimes format changes needed for the data, this can usually be accomplished without strongly typing the data.
When validation is necessary (usually isn’t and I try to steer clients away from doing validation in the integration layer) then using XML and schema validation is sufficient. No need to convert to native types/objects since a) I probably don’t have to manipulate them anyway; b) the schema validation has verified the string values meet the constraints.
Since IS supports more than just XML, I can also validate flat files too, using similar schema constructs.
Where manipulation is required, I generally do so on a case by case basis–and then the data usually ends up back as a string. Sometimes I keep Date objects around (a bit easier in some aspects than a string) but generally I convert date strings from one format to another using string formatting (which may temporarily convert to a Java object).
I disagree. As mentioned above, XML data are strings constrained to a certain format as indicated by an XSD–exactly the same way IS treats them. The classification of a field can indicate the constraints via XSD attributes, but the data is always a string. Whether one wants to convert the XML data to a native type/object will vary by integration.
Mostly because XML isn’t the only format that is supported. Also, IS (previously B2B Server) predates the popularity and success of XML. As an integration server, it must support more than just XML.
XML processing is one of IS strengths. It is almost trivial to work with XML. Serialization/deserialization to native types/objects is a Java environment thing (or C++ or C#, or whatever environment thing). If you have a strong desire to convert XML to/from Java classes, perhaps IS isn’t the right tool. In IS, serialization/deserialization is simply pointless most of the time.
Incidentally, it is serialization/deserialization that is at the root of most interoperability problems in SOAP RPC. That’s at least one reason why most people say to avoid RPC.
Yeah, these are good additions! (though I’m not all that enthused about .Net stuff)
Well that really wasn’t an option since I had to get the data into a Java class and then call a method on it. Pretty much had to be Java. And I had to use the rudimentary jcode comment stuff for the input and output document, since there was no way I was going to manually import 1000 xsd files and manually associate them as input and output docs to the services. That would be another feature missing from jcode, i.e mass import of xsd documents as service specifications.
Yeah I’ve heard this over and over, and I don’t want to start a flame war, but that is BS. Oops!
FLOW is not a complete language. It needs real constructs like try/catch/finally. Yes I know you can sort of simulate it with the sequence mess, but try throwing an exception (exit) from the ‘catch’ part. Gone Eaten. Worthless. Not safe.
Also refactoring a document change in Java or C# is soooo much easier than in FLOW. Those damn MAP thingys just won’t let go.
FLOW is only good at mapping and calling services. If/Then/Else, program control, etc it is not good at.
You’re entitled to code your IS stuff however you want. My favorite way is C# in 7.1 since they’ve made it so easy by actually generating the code to serialize/deserialize objects in and out of IData.
Whoa, my experience has been the exact oposite. I don’t know how to respond to this. We obviously approach coding from very different angles. I prefer a more safe, conservative approach.
Thanks for the discussion tho. It has been refreshing.
]Monty[
I can see the pain. I may have made that choice myself. But now you’re dealing with the pain of trying to use a facility in a way that wasn’t intended. Hindsight being 20/20, perhaps some code to convert the Java classes to IS services may have been the way to go?
What’s the method in the class that you’re calling? Is it for validation, translation, transmission, ??
[Edit] I see that you posted a request for doing this very thing back in August. Bummer that noone was able to help. And a bummer that the wM MF product line has been in flux as that may have been something to consider.
Bring it on. Trying to do the majority of work in IS using Java (or C#) is a recipe for frustration. If your preferred mechanism is to use Java/C# code, then I’d offer you’re using the wrong tool.
Was the use of IS thrust upon you? Or did you go voluntarily?
Java doesn’t implement MI “right” in the eyes of many but that doesn’t mean it isn’t a complete language. I agree that the exception handling mechanisms aren’t stellar (and I think exceptions are generally abused in “real” languages but that’s another discussion) but you can do what you need. In the catch block, set a var. Then outside the try/catch sequences, test the var and throw your exception (I do this in some cases myself).
Do you have any other “incompleteness” examples?
Agreed. Refactoring can be a major hassle. I’d bet that a third-party tool to help with this would be extremely popular.
I’ve been fortunate thus far to have avoided refactoring for the most part. Although there is a web services based interface I worked on that was a major deal to update when the wsdl was updated. Nasty. Tedious.
There hasn’t been a control structure yet that I couldn’t manage with FLOW. Some have posted their “banging their head against the wall” examples here but they’ve been solvable so far–with little effort. Do you have an example that has been a source of frustration?
Thanks!
Again, I think you’re probably using the wrong toolset. Why aren’t you using BizTalk? Lots of C# coding opportunities there and you won’t have to bother with the pesky FLOW stuff. Of course, there are issues with that toolset too but fighting against the grain of IS won’t be one of them.
The implication being that my approach is a free-wheeling, unsafe, devil-may-care approach?
Strong typing has long been the mantra of “safe” coding. Don’t get me wrong–when I work on application code, strong typing all the way baby! But in the integration layer, strong typing adds only heartache and issues. String representations are the most portable and interoperable. Converting to native types/objects in the integration layer is mostly unnecessary.
Besides, using XSD and schema validation provides the same type safety, when it is necessary. Validate the XML up front. If it fails, reject it. If it passes, there really is no need to convert to native types unless you must manipulate that data in some way–and even then, you may not need to convert to a native type.
In other words, the end points care, the stuff in the middle doesn’t (generally speaking). But sometimes the stuff in the middle needs to protect one of the end points. And in that case, the facilities are there to do so.
Admittedly, my “weak-typing” position is most likely in the minority.
You might find this thread interesting.
http://wmusers.com/forum/showthread.php?t=2943
My favorite quote (from Dan Green, original founder of wMUsers):
“Without sounding melodramatic, Java developers can significantly increase a project’s time-to-market and ruin your ROI.”
These other two may be of interest as well:
http://wmusers.com/forum/showthread.php?t=7965
http://wmusers.com/forum/showthread.php?t=9473
These all cover various viewpoints on the use of Java in IS.
Interesting response. Thanks!
I disagree. I think I am using IS in exactly the way that webMethods intended it to be used when service enabling legacy apps. I have not talked to anyone at webMethods, i.e. their chief architect, my account rep, the tech support people who would make that statement.
Can’t. I will state this again. The code to get to the mainframe is Java classes that use IBM’s CTG Java classes. Must be written in Java to get to these. No can do in FLOW.
Listen, you can point to all the threads you want about Flow being better than Java or C# or whatever, and you won’t convince me. Frankly, those things I read sound like people that really don’t know how to code, and maybe should stick to Flow. I’m a real professional software developer with 30 years of experience, and I’m using a bona fide language, not some flash in the pan visual scripting language obviously written and designed by a group with no formal language design experience. No hard feelings, but let’s drop the Flow over Java/C# discussion. It’s pointless.
You’ve got to be kidding, right? WebMethod’s BPM completely blows away BizTalk. Besides I’m using IS to service enable legacy apps, the perfect tool for what I want. Eventually we will use BPM on top of the IS services. BizTalk is a poor half-baked orchestration pig, that isn’t good enough to stand in BPM’s shadow. Ok, maybe that is a little harsh, but I have BizTalk experience, have done things in it, and I don’t think much of it.
]Monty[
It wouldn’t be the first time I’ve disagreed with wM folks! We’ve had our differences on the positioning of Broker and how IS is limited to connecting to just one and on how TN can be used for more than just interacting with external partners. But I digress.
I wouldn’t put too much credence in the relative silence of the account rep, or the tech support folks. Don’t get me wrong, I don’t harbor them any ill-will at all but we’ve all had our head-scratching interactions with them, right?
Chief architect? That’s another story. I would assume he’d tell you if the emperor had no clothes.
Perhaps I judged too quickly about how much Java you’re really doing. Given the use of CTG and the need to use Java to interact with it (and the 500 or so CICS transactions you need to access) the use of Java services to get there isn’t unreasonable (well, required actually).
Doesn’t CTG expose a services-based interface? I’m not sure, but I thought it did. Or maybe that’s recent. Or insufficient?
I’ve never stated that FLOW is better than anything. Just that it is the primary language for IS-based solution development and that for most integrations very little Java is necessary. I wasn’t trying to convince you about the supremacy of FLOW. Rather, I pointed out some links that had various points of view on the topic.
I don’t know if you do mostly FLOW or Java for your services. If you want to do things primarily in Java, that’s certainly your perogative. IMHO, that’s a mistake.
A little condescending, don’t ya think? I’ve found that people who don’t know how to code have trouble with FLOW too. They just don’t grok control structures and logic.
The people that seem to have the most complaints about IS and Developer are usually Java programmers that want IS and Developer to be like WS/WLS and Eclipse. Developer isn’t a Java development environment and IS, while based on Java, isn’t a Java app server or a J2EE container.
I wouldn’t want to give up Java services in any way. And it would be nice if Developer provide a smidge more help in editing and debugging. But sizeable Java development and execution is best done elsewhere, IMO.
Is the implication that I’m not a professional software developer? 
IS is not a strong Java development environment. Never was, probably never will be. But that is the point, at least in part. It preceded the popularity of Java. FLOW isn’t the greatest but for what it is intended for, it does okay. It’s been around for about 10 years now so the classification of flash in the pan may be a bit extreme. The strength of IS and FLOW is one of the reasons wM lasted as an independent for so long, IMO.
I believe FLOW was developed by one guy, but I’m not certain of that.
The debate about the relative merits isn’t pointless. I hope you have not dismissed FLOW services entirely. I’ll assume you’re familiar with the pros and cons of writing FLOW services and Java services, so I won’t bore you with that. I still hold the opinion that 90%+ of code for the majority of integration solutions in IS should be FLOW services.
Yes, it was a bit tongue in cheek.
All the analysts have been smitten with the wM BPM suite. It was the primary reason given by SAG for the wM acquisition. I haven’t worked with the 7.x stuff, but earlier stuff was just okay. Diagramming integrations is a long-time desire of IT to get the business folks to do there own durned solution development. I don’t why but we keep thinking that programming should be easy enough for everyone and we just need to give them the right tool for doing it themselves. Hasn’t happened yet!
But I still don’t quite get the appeal of BPM, even after having been involved with a large installation. Most places just aren’t ready for it. Have you done any proof of concept or sample stuff with it yet? If not, don’t underestimate the amount of effort it may take to get your existing services to play nice in the BPM sandbox. And the need to have guidelines for model development.
Yes, it is quite good for doing that.
Me too and me neither.
wow. this has turned into a gripping debate!
monty you are getting me very interestd in the .NET support in 7.1. Do you fancy writing a review for me?
I really want to combine my .NET skill with the best of wm where possible.
In fact I am trying to persuade our IT people to host our new IS on Windows not Solaris for the exact reason of giving the .NET capability going forward. Up hill battle though…