The shop that I am working part time with is new to Microsoft CRM. I just want to survey what projects have developers done to the system to extend its capabilities.
I can break the work I did into four sections:
Tailoring - Simple field level changes. A lot of this is just making sure the fields and language suited the business I was developing for.
Customisation - More complex changes, generally needing JavaScript and maybe ASP.NET. Some examples would be to use an IFrame and pass values to it from a CRM form. The IFrame would then do interesting things like mapping, charting or give you buttons to do other things. For buttons I would often times use JavaScript to replace the outerHTML in the HTML dom of an IFRAME to show a button rather.
Integration - using .NET to connect MSCRM to other systems. Connected it to Great Plains, Speech Server, SCOM (was called MOM back then), custom LOB systems etc... One interesting one I did was to develop a SSIS component that wrote into MSCRM via the web services.
Reporting - Building reports. In reporting services and in Excel. Excel made for great dashboards because of the dynamic update nature of it.
I have a few (war) stories up at http://www.sadev.co.za/taxonomy/term/7 if you are interested.
I (and others) have implemented a LINQ query provider for the web service layer http://www.codeplex.com/LinqtoCRM.
I did some work with CRM 3.0. My work enhanced the program and turned it into a Document Management app, where you could scan and upload documents based on a case, contact, customer, vendor etc. The .NET SDK back then could have used a bit more work, but I hear with newer versions of CRM it has gotten better. CRM allows for attachments but not at all levels, more at the case level.
We extended 3.0 to send text messages rather than email. There are tools available (for 4.0 at least) to do that now, though.
We also extended it to push service appointments through to Exchange, as due to the workforce being mostly mobile they did not have the CRM client for Outlook.
Two other major areas of development not yet mentioned are plugins and custom workflow assemblies.
Plugins allow you to intercept many of the messages that CRM processes to insert custom logic. The possibilities this gives you are endless because you can intercept all kinds of messages including Create, Update, Delete, and even Read!
Custom workflow assemblies are assemblies that you register with CRM that integrate with CRM's workflow UI. Often times, they perform simple tasks that are useful when modifying form data. Other times, they are more complex like sending status reports.
Custom workflow assemblies are always listed beneath the native options. In the screenshot, everything below "Stop Workflow" was added via a custom workflow assembly.
Related
Once an html page has been put together it starts to acquire dependencies on Angular and typescript.
This is not ideal for the web designer who really just wants to be able to view and modify their design. Usually this involves data elements too.
In our team the designer needs to be able to continue to work with html and stylesheets; they are not a separate contracted resource.
Is there a way to set up a project so that the web designer does not need to concern themselves with npm packages, Angular versions and data sources?
I have since had an idea...
As it happens I am a Linux user, the designer is a Mac user. I am wondering if it would be possible to create a project consisting of symlinks to html with typescript stubs.
A mock datasource might also be a viable solution.
SonarSource has said that they would be dropping support for Ruby on Rails. So assuming that we would need to use Web APIs from here onwards, what are alternate ways of writing your widgets? Has anyone tried any alternate ways of writing one? And how do you link said widget to the UI?
Short answer:
In upcoming versions of SonarQube, widgets and customizable dashboards will be progressively be removed. You will still be able to use the Web APIs to get all the data you want but you won't be able to contribute changes to the "dashboards" of the product.
Long answer:
SonarQube was initially designed to be able to inject and display any kind of information, mostly thanks to the customizable dashboards and widgets (that are indeed written in Ruby). While this helped getting widespread, the downside is that people started using it as a multi-purpose aggregator and reporting tool. One would add information coming from a bug tracker system, another one would add documentation information about projects, ...etc. The consequence is that soon, the global and project dashboards ended up being full of useless and useful information, everything mixed up together in a big mess.
So something had to be done to get back to what SonarQube is meant for: managing source code quality. Every information that can't be precisely linked to a source file should not end in SonarQube. Having said this, it becomes obvious that having a mechanism to define custom dashboards and widgets is just too generic. The web application must provide features that answer precise needs for a precise audience. This is why customizable global and project dashboards are progressively replaced by "hard-coded" pages which answer those use cases. This started with the new project home page introduced in the 5.x series of SonarQube and available in the latest 5.6 LTS. And we'll do the same with global dashboards in the 6.x series.
We have some JSP code to run in our pages.
There is a UI designer who will constantly update the UI but does not have Tomcat server. We prefer he doesn't because he isn't a programmer.
However, it is getting annoying to have to cut and paste the JSP related code each time he updates the UI.
Is there anyway to handle this issue? We prefer to keep the same files, but still have it so he can see his UI work without worrying about the JSP and when he checks in the new files, we don't have to cut and paste our JSP related code.
One example of such code, is that there are certain navigation menu items which are displayed depending on the user.
We are using Tomcat authentication. We could I suppose use AJAX to obtain the user information, but is that less secure? Everything else in the application is AJAX.
The problem here is that this person is not working with the team. Rather, he's creating work for them... and it goes both ways. Read on.
I both do and manage front end development. If this UI person was on my team, I would force him to set up a Tomcat server. He just needs to learn some things.
In effect, when implemented properly, JSP is not much different from any other server-side markup language for views, such as Rails + ERB, PHP, .NET etc... even Javascript templating engines (mustache, handlebars, etc.). The same condition checks, for-loops, auth checks - all basic view-layer logic that is needed is available and usable.
If he's on a Java project / team, he needs to learn the Java front-end. It's that simple.
His main tasks should be basic, and frankly, he shouldn't even need to install a Java IDE to do them. They are:
Get/push source code + analyze diffs (any source control client)
Build / deploy latest to his local environment (scripts or .bat files)
Work on the running app*
(*) The last part is where things get tricky. If you work directly on the running server and then accidentally run a fresh deploy before copying over your updates, you're screwed. If you use symlinks (which are also available in Windows), there may be files that only appear post-compilation, or locks, or sync issues when getting latest code - all creating problems.
The way I have found that works best is to work on the code repo location (pre-build), and create two scripts:
Build+deploy - stops running server, blows out directories and caches, builds latest, and redploys
Update - Synchronizes the View files and any other necessary directories with the deployment target. You must be sure to disable hot-deploy in the Tomcat config, or you'll get memory leak errors.
That said, and it should be obvious by now: Java is one of the most difficult ecosystems to develop UI's for. The compiled nature and complex environment requirements make development slow and tedious, with significant dependencies on different people or systems to make a decent product.
JSP itself, while capable as described above, is almost always organized badly, with various ways of includes, tagfiles, partials, frameworks - it becomes a UI person's worst nightmare. GSP (from Grails) solves a lot of the organizational issues, but will require flexibility from the dev team. Even then it is not an "ideal" solution.
JSP syntax - JSTL, C:tags, etc. creates even greater headaches. Front-end people who do not program, don't use IDE's and therefore don't have a way of looking up methods, objects, parameters etc. when writing or customizing conditional logic or loops. The dev team can help by pre-writing these out on the page, but any time there are changes or enhancements needed, it requires meetings, conversations, and compromise.
In the long run, you should abstract the Java app from a separate, more flexible, more capable front-end technology stack, using REST / JSON-based services to talk between the two. (Side note: For performance / apps with scale, ensure you are using either a custom protocol or Web Sockets).
My preference is node.js, because front-end developers can stick with the language they will know best: Javascript / JSON. But it could be anything that your particular front-enders are comfortable with and can do design with.
The key is to eliminate bottlenecks on both front-end and back end. Both tracks should be able to develop and iterate quickly, with the RESTFUL API being the key point of collaboration.
Lastly, for those of you who are aspiring front-end developers / designers but only know Java (or some other server-side technology), I CHALLENGE YOU to learn something new. User-facing technologies are in a constant state of change, and more recently that change has accelerated. If you want to have UI-competitive products, you need to invest in technologies that will make them competitive.
Can anyone recommend the best web-based technology/language for rewriting a ms-access front-end? I've already converted the tables to MySql and moved all the queries into stored-procedures. The language will need to be able to handle multiple result sets.
Also, I need the GUI to be as similar as possible to the current ms-access front-end. So the new language will need to have features including full CRUD, tabbed forms, datasheet style sub-forms, combo-boxes and reports.
I've dabbled a bit with html, css, php, javascript and java but are any of these capable or suitable? I've heard that Ajax or jQuery might be the way to go.
This is a misguided goal.
Web UI uses completely different paradigms because a web front end is stateless, with unbound data, whereas Access apps are stateful and bound. A 1:1 translation will be a disastrous way to implement a UI in the web browser, unless you invest a HUGE amount in AJAX development.
That said, you should look into Access 2010 and Sharepoint Access Services, which allow you to createn Access front end with web forms and web reports that can be run in the web browser unchanged. This would likely be an order of magnitude cheaper than rolling your own AJAX-based replacement.
We are in the process of doing this. In order to keep the "spreadsheet-style forms" that we have with Access, and which include ordering and filtering capabilities as standard on all screens, we took the decision to go for silverlight + Infragistic toolkit on top of it. Up to now, we have already developped a few screens with these tools, and are quite satisfied with the result.
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.)