I need to get cXml message from Ariba in BizTalk do some processing and send as cXml to another endpoint.
Please suggest some pointers to how this can be done in BizTalk 2013.
I've done a lot of BizTalk+Ariba and there are no real blocking issues, but Ariba makes it much harder than it needs to be. This is not a problem with BizTalk, it's Ariba.
You can download the DTDs (yes, DTD still) from cxml.org then use the DTD Wizard in Visual Studio to generate the Xsd Schemas.
There will be some issues due to constructs supported in DTD but not Xsd. I just delete the offending structures. Never had to use them.
Depending on what you do, the lack of a namespace may or may not be a problem. I'd just get started and see what happens.
If you have any problems, come back and I can look at how I fixed it.
Related
I know it may sound silly, but i worked for a client that seems not willing to pay me, but is making money with his website...i still have access to the ftp...so, i'm not going to tear down the website if he doesnt pay, but i would at least protect my code that i gave him...so in case i'm sure that he cant resell or use again...
http://www.zend.com/en/products/guard/
If you code for your client in PHP, this will prevent reverse engineering, and you can set the application to expire after a certain amount of time. There are numerous other licensing options available.
I think you have a deeper problem though, you should really talk to your client or get a third-party mediator to resolve this. At the very least, you should receive a deposit. Contracts will also give you some legal leverage, so you should have signed one before you started work.
what form is your code? html? js? java? c#? you can obfuscate js, for java (or .jar file) you can use the strip/pack tools as detailed here.
in general, obfuscation seems to be pretty effective for all of them (even html, if the bulk of it is generated through scripts :p )
Consider the next poor guy that your client recruits to manage that code... And consider the ramifications - because his impression of you will be based on that code!
If your code is written in ASP.NET, you should obfuscate it (Visual Studio comes with the community edition of Obfuscator), but there're probably better obfuscatation tools than that one.
On a side note, I got my code and last payment actually stolen by a client (the binaries not the code itself, but he managed to disassemble the code with help from a developer. Unfortunately it's too easy with .NET). This is one case where I really regret not obfuscating the code.
First, don't do anything that could be taken as a malicious attack against your client. Messing with their FTP after they have ceased communication could land you in hot water.
Second, if they haven't yet given you a cent for your work then AFAIK you still own the full rights to that work. (i.e. the copyrights on the code etc. you provided) If they use your code, without a license and without paying then they are committing copyright infringement.
This is all legalese, but I'm not a lawyer. Talk to an attorney before acting on copyright.
Let me start off by stating that I am a novice developer, so please excuse the elementary nature of my question(s).
I am currently working on a Flex Application, and am getting more and more confused about when to use server side scripting, and when to develop web services. For most of the functionality I am working on, I am taking various files from the user (client), uploading to the server for processing/conversion, then sending back to client in new format.
I am accomplishing most of this using asp.net generic handlers (ashx) files, but not very confident this is best practice. But at the same time, does making web services make any more sense? What would be considered best practice for this? Any suggestions would be greatly appreciated.
The way I look at it is as follows:
Web Services mean Established Best Practice.
For most of our development, we don't need to create "Web Services", or what I'm thinking when I think REST, SOAP, and the Twitter API. You only need to start doing that once you've got something you're going to be using every day for years.
Clean and DRY code will Lead you to Creating a Web Service
If you spend the time to clearly define the parts of your upload-process-render Architecture, and you find that it can be applied to almost everything you are doing, then all you need to do to make it a Web Service is define a clear, 1-2-3 set of rules for using the system (GET/POST data, etc.). As long as you are consciously building an architecture the whole way, you'll end up creating a Web Service if it's worthy. Otherwise there's no need.
It sounds like you have a clear workflow going, I don't know anything about asp.net though.
As far as it being confusing sometimes, and best practices, I suggest the following:
Create a Flex Library Project for your "generic ashx file handling" Flex classes. Give it a cool, simple name.
Create a .NET Library Project that encapsulates all the logic for your server-side file processing. Host it online and make it open source. I recommend github. Test it as you go, and document it, its purpose and the theory behind it.
If you don't have to do anymore work at this point, and it's just plug and chug, then you've probably arrived at something that might become a Web Service, though that's probably a few years down the road.
I don't think you should try to create a Web Service right off the bat. Just make some clean and reusable code, make a few examples, get it online and open source, have others contribute and give feedback, and if it solves a specific problem, then make it a web service. You can just use REST for now probably, and build your system around that. RestfulX is a great library for that.
Best,
Lance
making web services without any sense make no sense ;)
Now in the world of FLEX as3 with flash version 10, you can easily read local files, modify them with whatever modifcation algorithm and save local files without pinging server.
You only have to use webservices if you want to get some server data or to send some data to server. that's all.
RSTanvir
Flash / Flex uses a simple HTTP POST approach for file uploads, so trying to do that using SOAP web services will be problematic. Your approach of using ASHX here sounds reasonable to me.
To send / receive data that isn't file based (e.g. a list of files the user has uploaded previously), I would recommend looking at the open source Fluorine FX library. Fluorine uses AMF which is a highly performant way of doing data transfer with Flash. It's also purely configuration-based, which means you don't need to code against any of its APIs, just configure Fluorine to expose your .NET service classes. You could easily add attributes to those same classes to expose them as SOAP web services via WCF if you need that in the future. I would not recommend using SOAP with Flex however, due to the performance losses and also because the Flex implementation of SOAP has a history of bugs and interoperability problems.
We've made a big investment in Microsoft BizTalk Server 2009 and it works like a dream for all our asynchronous work. We want to do much more synchronous work with it, though, and that's why we're seriously looking into the ESB Toolkit 2.0.
However, I've had issue after issue with this toolkit, and my gut feeling is that it falls short of being enterprise-ready. In other words, there are just too many bits that need to be installed in the absolute correct sequence, and too many things that can (and do) go wrong - too much hacking of .config files to get it to work, documentation full of errors, exception messages with spelling mistakes, etc.
Anyone share that opinion?
Is anyone actually using this toolkit in a live production environment?
Have you got BTS 2006/2009 but decided against using ESB Toolkit?
Really interested to hear some opinions.
Thanks
Andrew
I think there are many developers and projects out there that found the same issues about the ESB toolkit that you describe. I've seen a handful of projects and companies leverage the toolkit but usually what I see is that the source code is used (not the MSIs and/or compiled code, the source is cleaned up and only parts of it are deployed on the project. I've seen the ESB portal be used the most for its "out of the box" error management features and since its ASP.NET I've seen and been part of extensions built for it. I think it will get there, kind of reminds me of the early years of the enterprise library, in my opinion it only got enterprise ready after 3-4 years of development.
We have spent a few years improving the ESB Toolkit, making is useful. We have a SharePoint web part (that can be used with SP Foundation).
There are quite a few enhancements. To name a few:
Re-submission at the point of failure (instead of the beginning of the itinerary)
Friendly XML editor (instead of a string editor)
Logging of business data
Ajax portal (no pressing F5 all of the time)
Visibility into all of the steps of the itinerary (what has happened, what is next)
Logging of who made modifications
Has any one got any advice or resources for best practices for handling errors and exceptions from within a webservice.
ie.
How much information needs to be reported back to the client?
Should ALL errors bubble their way back as full blown exceptions?
Is it common/advisable to wrap responses within a class which contains any error information? (i've seen a lot of production level services take this approach)
Thanks guys.
I think it depends on what the clients are expected to be. If it was all internal to me and I was using WCF for everything, then I might opt for exceptions because they are handled automatically and quite easy to deal with.
If I thought I was going to have clients other than myself, especially non .NET clients, then I would go for something far simpler.
If you don't know, then assume that you'll have other clients, because this would be a pain to change, and it's not that bad for the .NET clients.
At a minimum, return some kind of error code and a description. If you aren't expected to handle multiple languages, they can use the description -- if they need another language, they can use the code for looking it up.
I'm wondering what is the best way to handle error messages in my application.
Currently I'm working on a web application and all error messages are stored in the database and we get them by ID, negative is an error , and positive are success messages.
the problem is that is hard to maintain and keep tracking of text messages.
What are your approaches ?
Generally speaking, I keep the text of the error messages in resource files. If you're using .NET 2.0 or higher (Visual Studio 2005 or higher), resource files are automatically compiled into strongly-typed classes, making the code which accesses said messages much more clear and readable.
(EDIT: Having seen another comment which mentions localization, I feel honor-bound to mention it here as well: .NET resource files do an excellent job of localization. You can get the localized text of the resource via the exact same code, with just a few minor tweaks to provide CultureInfo.)
That said, it sounds like a part of this problem domain is a message number. Are these errors being thrown from the database (say, as part of stored procs or triggers)? In that case, then database storage most likely is the right place for them, if only because that documents them most closely to where the "magic numbers" are being used.
If you're going to localize them, I would use the English text as the key, and then perform a lookup into your storage of choice (an SQL-based database, file store, or what have you), and then return the properly localized string.
Should the requested key not exist in the store, you could yield a plain-text error, perhaps e-mailing a developer?
For more inspiration, see GNU gettext.