Related
Where can I find a list of BMC Remedy 3rd party integrations? I have found nothing on their website, and their sales department put me in touch with the customer services which wouldn't take my call because I didn't have a customer number.
My company is looking into using BMC Remedy as a customer incident system, and it would be nice if I could integrate it with some software. For example, we could have an internal development tracking system such as Jira, Redmine, MantisBT, Trak, etc. which would integrate with Remedy. Or, have Rememdy itself integrate with something like Hudson or CruiseControl.
So far, I've found nothing that seems to integrate with Remedy -- even with software packages that have a ton of integrations like Hudson and Jira. I don't really care if there are third party proprietary integrations, but I'd like to make sure they already exist and not All you have to do is hire someone at $400 to program everything for you. I want to make sure that there is something now and not be promised it can be done, then find out you really can't do it.
I may be a bit late to the party here, but I wanted to make this info available for anybody who happened to be searching for this answer in the future. BMC Remedy has an API in Java, which uses a native library in C, as well as bindings for Perl and other languages capable of calling native code. If you can integrate with any of those languages, you can write a custom integration program and integrate with that. As 'Gary L' mentioned, Remedy can also expose any form as a web service, which, in my experience, have simple interfaces.
Since the original question was asked, BMC have created a doc with a wealth of information on their Wiki. A Swedish company, RRR, has also collected every version of the Remedy Java API and required native libraries on a single page. It appear that you no longer need a support ID to access these pages and download the API files.
Hopefully somebody finds this helpful!
Your definition of "integrate" is different from their version. Their version of integration means that if a source system exposes its data, then you can configure ARS to retrieve that information and map it to classes (forms) within their system. They have a "generic" integration system that you have to customize. It has three broad areas:
If you can connect directly to a 3rd party database and see its schema, then you can perform
retrievals of that information. We use Oracle today.
They have a java API that allows you access the ARS system for custom code (I do a lot of this).
Flat CSV file importation of data from a source system into ARS (after export).
I looked at their online support for the systems you mention (Jira, Redmine, MantisBT, Trak) and do not see anything that would accomplish any of the three above without your own customizations. With the work that I've done on this system it doesn't surprise me.
I work on a project today that writes custom code doing the items above. It is a system that is configuration/development heavy for us. Your comment: "All you have to do is hire someone at $400 to program everything for you." is not too far off from what we have to do with the system.
There is another option for Remedy integration: Web Services.
BMC Remedy makes it easy to create web services (WSDL). It creates the SOAP and XML for you. When you buy Remedy Incident Management module, it includes out-of-the-box web services that will allow it to consume and/or publish web services which make it easy to integrate with other systems on the intranet or externally. There are BMC publications which provide details on ITSM integration --- but again you will need a customer/support ID to get it from BMC's website.
Yes and no to the Web Services integration. The Version 8 system I was working on had some web services available, and they were incomplete. So I was able to do a number of functions (mostly read-only), specifically for custom display and Change Request checking, and submission of a Change Request and a Work Order. But many functions had no web service, and I ended up brute-forcing through the web user interface (with a customized browser control) to change dates on tasks, or make tasks. Ugly, but effective. There are mid-tier JavaScript calls that can be used, if you know the secret function name and can deal with the dynamic naming convention in play. For Remedy users who are desperate for some integration, there are ways it can be done.
few OOTB integrations are possible with BMC Products but if you want to do it with other you have to write webservices(REST or SOAP)
Companies like IBM or cisco has made connectors for integration with Remedy.
Just adding more detail here:
I also do a ton of direct SQL for remedy integration.
If you're careful and know what you're doing, you can have a stored proc create legal/valid records in a remedy table. (If you do it wrong, the records won't load in the client and in older versions of the windows client can actually crash the client software.)
Simple question, I want to know is Java free (especially for web development). Later on if I've build a large website, will the servers, databases cost me much like in .net for example?
Cheers.
Java is free. Check licences of frameworks you're using, but you shouldn't worry about that since most of them are free.
Servers (physical) will, of course, cost you.
There are free application servers like Glassfish and JBoss.
There are free databases like mySQL and PostgreSQL.
So, you can get away with everything being free except hardware and, possibly, hosting of your web app.
Yes and no - depending on how big your site gets, you may be required to invest more money into better servers/databases.
It's not really something that can just be answered, without looking into the future.
Update, as of 2021
Be sure to read the document prepared by pillars of the Java community, Java is Still Free. This document provides a short overview as well as a longer section with all the gory details.
Understand that Java is a set of specifications, not a product.
Java Language and Virtual Machine Specifications
JEPs and JSRs
Many vendors provide binaries or installers for an implementation of Java. Nowadays, all of those implementations are based largely or entirely on the OpenJDK project. Participants including Oracle, IBM, SAP, Apple, Azul Systems, and more have banded together to pool their best technologies for implementing Java as open-source free-of-cost.
The OpenJDK project provides only source-code. Various vendors build that source code to provide binaries or installers for you and me to conveniently put Java on our computers. Some of their distributions of Java are available free-of-cost, and some are commercial with paid support. Some are general-purpose JVMs, and some are special-purpose. Some are a basic JDK and some have bundled extras.
Here is a diagram I made to help you in choosing a vendor for a Java implementation.
And some considerations to think about when choosing a vendor.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
For the last month or two I have been trying to wrap my head around Magento, with a moderate degree of success. While it has been billed as the next great e-commerce system, I have come to realize that although it has some pretty neat features... in reality it's a step backward for open source projects as far as development and community is concerned.
A look at the forums and it's full of developers complaining about the lack of documentation, the joke of an official wiki (there are people who post ads on the official wiki), and also reports of the upgrades breaking core functionality. Most of these posts and valid bug reports are ignored by the Magento staff. A request for some XML diagrams of the core modules has been ignored for a year!
The IRC chat is pointless as a lot of new users are greeted by moderators who tell them to RTFM!
It seems like there is a conflict of interest for the company that runs Magento: they now sell an enterprise version of Magento and their core business is in providing support for Magento users. I feel it isn't in their best interest to provide documentation for the over-complicated architecture (going through eight layers of folders to update just a single image).
Is Magento an open source system?
I understand your frustration all too well, but open-source doesn't mean documentation or support.
The attitude the Magento team has is "here's the program, here are some forums and a little documentation, from there on you're on your own". Sounds bad, but they've already released for free what must have taken thousands of person-hours to create. You have to be at least a little grateful for that.
As for documentation and support, you can't really expect them to keep working for random strangers for free. Besides, few of those people who complain about lack of documentation come back later on to write how-to guides when they finally understand the system.
Yes, without question Magento is open-source. Yes, it is a great product. Yes, it is slow.
However, Magento seems to be missing the rich community that often accompanies open-source. For example Drupal, Firefox, and Ubuntu have a crazy passionate base. The Magento community should step up to the plate to fill in the gap since the official documentation, wiki, and forums are lacking. It seems the further away from Varien you get, the better the community support.
I imagine Varien does this on purpose - since it is in their interest to have people purchase support from them.
Perhaps I am being too hard on them. The project is young, and the community is still evolving. It might help if there was a community-wiki-hub that was independently operated by the community. Sites like snippi.net, Stack Overflow, alanstorm.com, westwideweb.com, inchoo.net, and the IRC channel are doing a great job at fueling the community so far.
Magento is technically Open Source. However, it does not embrace the concept to its fullest and include open/transparent development. All development and direction is done behind closed doors.
They release snapshots of the code at their leisure and have zero feedback on bug fixes. We've been trying to get some sort of dialog going for core development fixes and additions, but nothing has happened so far.
As it uses an OSI approved licence for its community edition, the answer is yes, it is open source. If you don't like the product or service they are providing, feel free to band together with like-minded peers and fork it!
Yes, it is, however it is extremely slow.
I don't count this as open source as we have come to expect it. They have set up a system where what you contribute to the project is not necessarily incorporated for the benefit of all. By withholding features they are making you as a developer work for them. This is a bait and switch for the non-developers. If you start using it and grow to the point that you need one of the enterprise features you can't get it from the community because that feature is effectively reserved. So just move to enterprise with a 10 yr. cost of ownership of more than $89,000. I actually like the idea of a professional support organization on an open source project. But that is not what this is. I am running for the exit.
Can you download it, edit the source to fit your needs, and redistribute ever for commercial use?
So, it is open-source. The code, at least.
What about the documentation, support? It's another way...
Man, I'm sorry, but you can't think that if someone creates an open-source project, then it is bound to it and MUST follow the support every day... Maybe he should or, better, he will be great if do so.
Probably you're right; there is a conflict of interest, and maybe they used the open-source edition to grant popularity and then sell the enterprise-edition - I don't know; I just gave a quick look at Magento in the past.
Yes, the community edition is opensource under Open Software License v3.0.
The Enterprise Edition however, is not opensource.
Someone on Twitter was kind enough to forward this link to me, and so I'm dropping a quick note to say that I think that you wouldn't come to our forums and see that kind of negativity. I don't see it, and I'm there pretty much every day ;)
In regards to contributing -- I think someone was asking about contributors for Magento and yes, you too can become a contributor. And yes, there are ways that you can contribute to EE as well.
http://www.magentocommerce.com/blog/comments/be-part-of-the-solution-become-a-magento-contributor/
If you have any questions, feel free to contact me → rhonda at magento :>
Yes, Magento is an open resource. It is true that it is very slow, but it has great functionality and features than other open resources.
It is complicated to understand, but it strictly follows the MVC architecture.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I'm looking for a free/open source collaborative project manager that can be deployed internally in my workplace that would act similar to Codeplex or Sourceforge. Does anyone know of something like this, and if so do you have experience with it.
Requirements:
Open Source or Free
Locally Deployable
Has the same types of features found in Sourceforge / Codeplex
Issue/Feature Tracking
Community Interaction (ie. Voting, Roles, etc.)
SCM Integration (Optional)
.NET/Windows Friendly (Optional)
Every business ends up having internal utilities, and domain specific apps that developers create to make life easier. Given the input of the internal developer community they have the potential to become much better (can you say GMail...), and I would simply like to foster such an environment internally by providing an easy place for that interaction to take place.
UPDATE:
So I like what I am seeing in both Trac and GForge, but both are heavily geared towards UNIX/Subversion environments. I should have specified this, but we are a MS shop from top to bottom. How practical do you think it is going to be to try and use these in a MS .NET environment? Would that be like trying to shove a square peg through a round hole?
I like redmine for this: http://www.redmine.org. The only thing it's missing from your criteria is voting, but there might even be a plugin for this.
Trac is also popular (http://trac.edgewall.org) but it lacks suport for aggregation of data across projects.
Try GForge, it's a SourceForge fork and has most of its features.
I agree, Trac should work. IMHO setting up Subversion should be relatively easy on Windows too, there are great Windows clients for it (tortoiseSvn), and Trac runs on python, so it will work on Windows too.
Other advantages of Sourceforge Enterprise are these plugins. There are extra plugins for Visual Studio wich can be found here and here.
SourceForge Enterprise Edition 4.4 is available for free for up to 15 users. We use it for our development team and another development team where I work.
It's been working great for us. It has subversion and cvs built in (whichever you wish to use). If you plan on accessing it over the internet you might want to enable HTTPS. I had to do a little finagling to get HTTPS to work correctly (finding the right CentOS packages to install). If you wanted to use this solution with HTTPS I wouldn't mind if you sent me a message asking for help.
It comes with a VM for VMWare Player:
http://www.collab.net/downloads/sfee/index4.4.html
Launchpad has support for Code Hosting and version control, Bug tracking, Blueprints, Answers, Polls, Translations, etc.
Launchpad is used by the Ubuntu Project.
A few weeks ago, Launchapad was released as open source.
I was just wondering the same thing, something like Trac but in .NET, after a quick GOOGLE search (I have never tried these tools) I found
sharpforge (This no longer looks free!)
I like how the site .netTiers looks.
They use screwturn wiki.
It is totally free if you fulfill all GPLv2 statements.
Assembla and BeanStalk are nice, both have things like; wiki, discussion, alerts, chat, ticketing, Trac, Git and Subversion
What about Trac? It's pretty simple, but does it's Job for a lot of Open Source projects.
I would concur on the Trac suggestion. I use it both for an open source project and for an internal project. It has decent issue tracking and integration with Subversion which allows links between tickets and subversion checkins. It also has an integrated wiki, which can be of some use for documentation. Although we do not use it for voting / community type features, I know there's a number of addons to it that might serve this purpose.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
In evaluating different systems integration strategies, I've come across some words of encouragement, but also some words of frustration over BizTalk Server.
What are some pros and cons to using BizTalk Server (both from a developer standpoint and a business user), and should companies also consider open source alternatives? What viable alternatives are out there?
EDIT: Jitterbit seems like an interesting choice. Open Source and seems to be nicely engineered. Anyone on here have any experience working with it?
BizTalk Server's key benefit is that it provides a lot of 'plumbing' around deployment, management, performance, and scalability. Through Visual Studio, it also provides a comprehensive framework for developing solutions, often with relatively little code.
The frustration and steep learning curve that others mention often comes from using BizTalk for the wrong purpose and from a misunderstanding about how to work with BizTalk and message-oriented systems in general. The learning curve is not as steep as most people suggest - the essential part of the underlying learning actually focuses on changing thinking from a procedural approach to a stateless message-based approach.
A drawback people often cite is cost. The sticker price can seem to be quite high; however, this is cheap in comparison to the amount you'd spend on developing and supporting features on your own.
Before you consider alternatives, or even consider BizTalk server, you should consider your organization's approach to integration and it's long term goals. BizTalk Server is great in cases where you want to integrate systems using a hub and spoke model where BizTalk orchestrates the activities of many applications.
There are other integration models too - one of the more popular ones is a distributed bus (don't confuse this with the term "Enterprise Service Bus" or ESB). You can also get BizTalk to work as a distributed bus and there are alternative solutions that provide more direct support. One of the alternate solutions is an open source solution called nServiceBus.
When considering whether to use a commercial product like BizTalk, verses something else (open source or developed in house), also consider maintenance and enhancements and the availability of the necessary skill-set in the marketplace.
I wrote some articles that go into more detail about the points I discussed here - here are the links:
Why BizTalk?
Top 10 BizTalk Mistakes
Extensibility Features in BizTalk Server
Open Source Integration with nServiceBus
My experience with BizTalk was basically a frustrating waste of time.
There are so many edge cases and weird little business logic tweaks you have to make when you are doing B2B data integration (which is probably the hardest part of any enterprise application) that you just need to roll your own solution.
How hard is it to parse data files and convert them to a different format? Not that hard. Unless you're trying to inject a bloated middleware system like Biztalk into the middle of it.
As a BizTalk consultant I have to agree at least partly with Eric Z Beard, there are a lot of edge cases that take up alot of time. But quite a few scenarios are handled extremly smooth as well, so it all depends IMO. But when you (Eric) call BizTalk bloated I have to disagree! We've found that the performance and reliability is excellent, it's flexible and comes with a lot of good adapters out of the box.
BizTalk needs to be used correctly,
I am a BizTalk developer and my experience with BizTalk is quite good.
Its reliable, performant, scalable, contains a lot of built in architectural patterns and build in components to make integration easy and fast, you get security, retries, secondary transports, validation, transformation etc... and what ever you dont have build in with BizTalk you can easily customized with .NET code, its basically a hard earned integration system and you get all this in one box.
BUT you need to know how to implement BizTalk correctly, not once I came across solutions that where implemented and often also architected incorrectly.
but the real benefit of BizTalk is that you can implement small solutions and scale up whilst most other integration systems from big vendors will only sell a whole integration pack which can cost much more.
BizTalk is considered the most complicated server from the house of Microsoft.
So any body saying BizTalk is not good dosent know BizTalk period.
We evaluated BizTalk at our company and were really disappointed.
We are using IBM WebSphere Transformation Extender (which has lots of (other) problems, too) and the mapping tool of BizTalk is a joke in comparison to WTX.
The graphical tool is not really usable for complex mappings (we have schemas with a few hundred fields in repeating groups) and if you do more than the usual "concat first name and last name to name" mappings, you will be tired of the graphical approach (for example the arguments of the functoids in the graphical mapper are not labeled and the order in which you connect fields to these arguments is important).
The XSLT-Mapper was usable but not really convincing, and even the microsoft rep told us to use a tool like XMLSpy for XSLT and load the resulting XSL file into BizTalk.
A third approach to mapping is to use C#-Code for the mapping, which was not acceptable for us as a general approach (we don't want to teach everyone C#).
In addition to the mapping tool we did not like the deployment in BizTalk. In order to deploy your process, you need to make lots of settings in different tools and places. We had hoped to find a mechanism like a WAR file for Java Web Applications in BizTalk, so that you can give one archive for your whole process solution to your administrator and he can deploy it.
We've been using BizTalk since version 2004, and now have a mix of versions 2006 R2 and 2004 running. I found that the learning curve was quite severe, and development time for solutions is not always quick. Those are definitely shortcomings. Where BizTalk really excels is in its fault tolerance, gauranteed delivery, and performance. You can rest assured that data will not get lost. Retry functionality and fault tolerance robustness is baked in so generally speaking if systems are down BizTalk will handle that and successful delivery will occur once systems come back on line. All these issues such as downtime, etc that are important in an integration scenario are handled by BizTalk.
Further, generally speaking when developing solutions BizTalk abstracts the communication protocols and data formats of the native systems by dealing with everything as xml, so when developing solutions, you typically don't have to wrote code specific to those systems, you use the BizTalk xml framework.
In the last year, we've implemented a java open source engine called Mirth for our HL7 routing. I found that for HL7 purposes, the HL7 adaptor for BizTalk is a challange to work with. Management dicated that we use Mirth for HL7 routing. Where BizTalk falls down in terms of learning curve, Mirth makes up. It is far easier to develop a solution. The problem with mirth is that it doesn't really have any gauranteed delivery. Most of the adaptors (except for hl7) have no retry functionality so if you wanted that you'd have to write your own. Second, Mirth can lose date if it goes down. I would call it very easy to use (although there is no documentation) but I'd be hard pressed to call it an enterprise solution. I'm going to check out jitterbit which was mentioned by someone else.
We used BizTalk for a couple of years, but gave it up for our own custom framework that allowed more flexibility.
There is always Sun's (now Oracle) OpenESB framework. Its generally speaking a smaller, lighter version of Biztalk but with roughly all the same features.
You do get to write more code with it, though.
Its Open Source as well.
In the OSS space (though I've never used them as a BizTalk replacement personally - this is anecdotal) you can use one of the Java/J2EE Messaging engines such as OpenMQ (which is the Sun enterprise one rebadged and without support). If you need Orchestration / Choreography (i.e. SOA/ESB pieces) on top of this, you could look into something like Apache Mule
My experience with BizTalk and doing B2B integrations is that most organizations do not truly do schema first design or fully understand xml standards for that matter. Most tend to weave objects and hope they materialize into meaninful schemas. In an enterprise environment, this is backwards.
BizTalk does have a learning curve, but once you get it you are rewarded with durability, performance, true scalability, and extensibility. Like most have said though, it best to make sure it meets your needs and contort your needs to BizTalk.
In the past I have worked with BizTalk 2004 through 2009, and another product called webMethods.
I have no direct experience with JitterBit, but I have heard very good things from coworkers.
I came across Apatar (unable to post url, but Google finds it) while looking for a solution cheaper than BizTalk. I have yet to try this out.
My last company had many problems with BizTalk being too complex and ridged, but I can’t help but think this was mainly down to the implementation the consultant did.