We are all new to stuff sometimes and I am currently quite new to Resco.NET and the JavaScript API it has. There is quite a lot of information and examples on Resco's site regarding this but you know how it is when you get going, you're always looking for something that just isn't there. Today I thought I was missing some vital part of how to parse the data, turned out I was addressing the fields incorrectly, so I thought I'd share it with you in case you ever got into the same spot.
Well, my current Customer likes the Resco mobile client a lot. They like the ability it has for configuration and the fact that it is so configurable and even has API:s allowing us to make custom webpages for them that they can take offline, as Resco does support full offline.
Back to my problem, I was trying to show some data from the account entity on the html-page and as I had previously tried this, I had no problems with the name field. However, when I tried retrieving a field that we had created, let's call it "Type" I looked in the list of fields in Woodford as I thought this was their view of the fields and hence how I was to address it. The name it showed was the weird REST-endpoint name with Camel-case "crmk_Type", but I didn't Think to much about this and used it in my code. The result was that I just got "undefined" as the returned value from the Resco JavaScript Bridge. It took me quite some time and a very helpful support guy at Resco before I opened the form editor in Resco and noticed that the field name set there was the normal name, used in the database/soap webservice, "crmk_type". Upon noticing this, I tried the lowercase version and it worked like a charm.
My conclusion is hence that the field names that are to be used in the Resco JavaScript bridge are the lowercase field names, not the Camel case versions, despite the fact that these are the once that you see in the Field list in Woodford. Also, make sure the field that you are addressing has been included in the the field list. This might be changed in the future. If so, I hope to be able to write an update on the subject.
Here is a link to the Support page at Resco.NET where you can download the bridge file and also at the far bottom, go to the reference pages for the Bridge. http://www.resco.net/mobilecrm/support.aspx
Gustaf Westerlund
MVP, CEO and owner at CRM-konsulterna AB
www.crmkonsulterna.se
"Always start with where the error is, then what the error is" I am MVP, founder and CTO at CRM-Konsulterna AB a company specializing in only Microsoft Dynamics CRM.
Showing posts with label Javascript. Show all posts
Showing posts with label Javascript. Show all posts
Saturday, September 13, 2014
Wednesday, April 30, 2014
Resco javascript Fetch all account example
I have
recently been working on a Proof-of-concept for a customer with the Resco.net mobile platform. It is the first time I have been working deeply with it and I
really like it. The woodford customization tool is very powerful and easy to
use. It also allows customizers to add custom components such as offline html
and js-components that can be used to extend the built in functionality where
the standard forms do not meet the customer’s requirements.
<head>
<title>Account List</title>
<script type="text/javascript" src="JSBridge.js"></script>
<script type="text/javascript">
function writeError(text) {
var error = document.getElementById("errortext");
error.innerHTML = error.innerHTML + "
" + text;
}
function callbackAccountsLoaded(res)
{
writeError("In callbackAccountsLoaded")
writeError(res);
}
function callbackAccountsFailure(res)
{
writeError("callbackAccountsFailure")
writeError(res);
}
writeError("Start!");
var account = new MobileCRM.FetchXml.Entity("account");
account.addAttribute("name");
account.filter = new MobileCRM.FetchXml.Filter();
account.filter.where("statuscode", "eq", 1); // which have “Active” status
fetch.execute("Array", function (res) { callbackAccountsLoaded(res); }, function (err) { callbackAccountsFailure(err); }, null);
}
catch (e)
{
errortext("Error: " + e.message);
}
}
</script>
</head>
<body onload="onAccountLoad();">
<div style="height:300px;" id="errortext"></div>
</body>
</html>
Gustaf Westerlund
MVP, CEO and owner at CRM-konsulterna AB
www.crmkonsulterna.se
In this
case my customer wanted me to prove that it was possible to create an overview
screen for an account showing lots of related information on a single screen.
As Resco does not intrinsically support subgrids, like Microsoft Dynamics CRM
does, you have to create this with a custom html which loads this data from the
offline Resco storage. In theory this shouldn’t be too hard. It proved to be a
bit more of a challenge, especially since the Resco Woodford manual contained
some errors why I thought it might be a good idea to publish an example of how
a complete code example of how to fetch a list of accounts wrapped in a working
html-page that can just be copy-pasted into a file and tested out. This was one
of the issues I had as just getting a simple base-line to work from was quite a
lot of work.
So, without
any more bells and whistles, here is the code:
<!DOCTYPE html>
<html><head>
<title>Account List</title>
<script type="text/javascript" src="JSBridge.js"></script>
<script type="text/javascript">
function writeError(text) {
var error = document.getElementById("errortext");
error.innerHTML = error.innerHTML + "
" + text;
}
function callbackAccountsLoaded(res)
{
writeError("In callbackAccountsLoaded")
writeError(res);
}
function callbackAccountsFailure(res)
{
writeError("callbackAccountsFailure")
writeError(res);
}
function onAccountLoad() {
try {writeError("Start!");
var account = new MobileCRM.FetchXml.Entity("account");
account.addAttribute("name");
account.filter = new MobileCRM.FetchXml.Filter();
account.filter.where("statuscode", "eq", 1); // which have “Active” status
var fetch = new
MobileCRM.FetchXml.Fetch(account);
writeError("Sending");fetch.execute("Array", function (res) { callbackAccountsLoaded(res); }, function (err) { callbackAccountsFailure(err); }, null);
}
catch (e)
{
errortext("Error: " + e.message);
}
}
</script>
</head>
<body onload="onAccountLoad();">
<div style="height:300px;" id="errortext"></div>
</body>
</html>
Some of the
important points here are:
1. account.filter.where needs to be
used instead of using account.where directly as indicated in the example in the
Woodford manual. It also needs to be instantiated with the “MobileCRM.FetchXml.Filter();”
2. The fetch.execute is referencing two
callback functions, one for success and one for failure. Make sure these references
exist and have the correct number of arguments.
3. I have not found any decent way of
debugging javascripts within Resco. I would be more than happy to be corrected
here. Using alerts will not work on all platforms (Resco indicates alerts do
not work on Windows 8 RT for instance). Hence I have created the
errortext-method which outputs text in a log-file manner to a div at the end.
Make sure that the height is enough.
4. To be able to load information on the
currently edited object, if the iFrame is shown in the context of an account
for instance, then MobileCRM.UI.EntityForm.requestObject() has to be used.
5. The first parameter of fetch.execute indicates how the result is to be formatted.
In this example I have chosen “Array”, but there are other choices like “JSON”
and “XML” as well. Please refer to the Woodford manual for more information on
this.
6. Do try to use try-catch around a lot
of this as any errors will otherwise just not show when run. If there is an
error, you can display the message and at least get an idea of what was wrong.
7. When developing, I like to use
Windows 8/8.1 and maybe a CRM Online/IFD environment as that will allow me to
install the Windows 8 version of the Resco CRM to try it out. The different
platform clients for Resco are 95% identical, some UI differences and I have
seen some other differences as well, but in general, it will speed up
development a lot and you will only have to do the final development tests on
the iPad/Android device.
If I get a
lot of interest in this, I will publish more on this subject. As mentioned
earlier, I havn’t found that much community content on Resco, the mobile client
I currently feel is the premier choice, as the Microsoft Mobile client is a bit
simpler in its design, features and also customizabilities.
Gustaf Westerlund
MVP, CEO and owner at CRM-konsulterna AB
www.crmkonsulterna.se
Monday, February 23, 2009
Errors when programmatically attaching events in forms
Today I had a very weird error. I had two datetime fields on a form, one on the first tab and one one the second. Let's call them date1 and date2 to make it easier.
I attached an event in the onload by using
crmForm.all.date1.attachEvent("onchange", myFunc1);
and for the date2 field:
crmForm.all.date2.attachEvent("onchange", myFunc2);
The weird part was that if I changed date1 first and then date2, myFunc2 didn't fire. But if I first changed date2 and then date1, both fired as they should.
So I tried just adding an alert instead using the normal onchange method via the form editor in CRM and that triggered every time, just as it should, so something is different.
The simple solution seemed to be to move date2 from the second tab to the first. That got everything working just as it should.
I havn't tried it but I think that one could also write a method that confirms all the event attachments and then calling this at the end of every onchange triggering function and perhaps some extra time when the tabs are changed to make sure the events are bound correctly.
I have checked the documentation in CRM for if this kind of runtime event attachment might not be supported but my interpretation of the text is that is should be all right according to it. The closest paragraph in the unsupported customization section is the following:
"The use of custom HttpModules to inject HTML/DHTML into the Microsoft Dynamics CRM Forms. "
As I wrote, my interpretation is that attaching events (not even overwriting the onchange), should be ok according to this since we arn't injecting anything, just adding an event listener. Hence I feel that this must be interpreted as a bugg in CRM.
Gustaf Westerlund
Microsoft Dynamics CRM Architect
Logica
www.logica.com
I attached an event in the onload by using
crmForm.all.date1.attachEvent("onchange", myFunc1);
and for the date2 field:
crmForm.all.date2.attachEvent("onchange", myFunc2);
The weird part was that if I changed date1 first and then date2, myFunc2 didn't fire. But if I first changed date2 and then date1, both fired as they should.
So I tried just adding an alert instead using the normal onchange method via the form editor in CRM and that triggered every time, just as it should, so something is different.
The simple solution seemed to be to move date2 from the second tab to the first. That got everything working just as it should.
I havn't tried it but I think that one could also write a method that confirms all the event attachments and then calling this at the end of every onchange triggering function and perhaps some extra time when the tabs are changed to make sure the events are bound correctly.
I have checked the documentation in CRM for if this kind of runtime event attachment might not be supported but my interpretation of the text is that is should be all right according to it. The closest paragraph in the unsupported customization section is the following:
"The use of custom HttpModules to inject HTML/DHTML into the Microsoft Dynamics CRM Forms. "
As I wrote, my interpretation is that attaching events (not even overwriting the onchange), should be ok according to this since we arn't injecting anything, just adding an event listener. Hence I feel that this must be interpreted as a bugg in CRM.
Gustaf Westerlund
Microsoft Dynamics CRM Architect
Logica
www.logica.com
Thursday, August 23, 2007
Java, javascript, jscript and so forth
When developing software customizations for SharePoint and MS CRM 3, javascript is often used. It can easily be confused with the totaly unrelated language java. Mennotk's blog has a posting linking to another blog that describes in a bit more detail what javascript, jscript and so forth really is. Being a developer in MS CRM and SharePoint, where this is one of my main tools, I found this quite enlightening and it sheds some light on some question marks I personally had on the subject of javascript and client side scripting.
Please have a look if you are interested: http://blogs.msdn.com/gauravseth/archive/2007/08/15/the-world-of-jscript-javascript-ecmascript.aspx
Gustaf Westerlund
CRM and SharePoint Consultant
Humandata AB
www.humandata.se
Please have a look if you are interested: http://blogs.msdn.com/gauravseth/archive/2007/08/15/the-world-of-jscript-javascript-ecmascript.aspx
Gustaf Westerlund
CRM and SharePoint Consultant
Humandata AB
www.humandata.se
Wednesday, August 22, 2007
Javascript event handling and dynamic lists in SharePoint
As many of you already know and probably have used, it is possible using javascript to create dynamic drop-down-lists. For instance one drop-down list that selects country and another that lets you select a city in that country. Depending on which country you select, you want the options in the city drop-down to change.
This is a quite common task in MS CRM where javascript is a common tool. In SharePoint however, javascript isn't as common. I am currently working with a colleague of mine, Sebastian Tegel, at a large swedish customer of ours. They had this requirement on some metadata in a SharePoint library so Sebastian and I used the same principles as I usually use in MS CRM to create dynamic drop-down lists in SharePoint. Sebastian has a very nice and instructive posting on his blog on how this is done. Please have a look at it: http://sebastiant.blog.com/2023682/
In the posting before that, he also describes how to create your own custom edit form for a document properties page. This is very useful in these cases, so please have a look at that as well. (http://sebastiant.blog.com//custom+forms/).
Gustaf Westerlund
CRM and SharePoint Consultant
Humandata AB
www.humandata.se
This is a quite common task in MS CRM where javascript is a common tool. In SharePoint however, javascript isn't as common. I am currently working with a colleague of mine, Sebastian Tegel, at a large swedish customer of ours. They had this requirement on some metadata in a SharePoint library so Sebastian and I used the same principles as I usually use in MS CRM to create dynamic drop-down lists in SharePoint. Sebastian has a very nice and instructive posting on his blog on how this is done. Please have a look at it: http://sebastiant.blog.com/2023682/
In the posting before that, he also describes how to create your own custom edit form for a document properties page. This is very useful in these cases, so please have a look at that as well. (http://sebastiant.blog.com//custom+forms/).
Gustaf Westerlund
CRM and SharePoint Consultant
Humandata AB
www.humandata.se
Friday, August 10, 2007
Problems with read-only fields...
When creating javascripts in general and when working with AJAX-based javascripts (javascripts that access server based information) specifically, it is not uncommon to update attributes in CRM-forms. If these attributes are “Disabled” using the form-editor or are disabled using javascript in with the following code:
crmForm.all.xxx_myfield.Disabled = true;
Then any updates to the data of this field, will NOT be saved when the form is saved. There is a way to bypass this and this is to set the attribute to “Read only” instead, with the following javascript code:
crmForm.all.xxx_myfield.readOnly = true;
This will disable any editing of the field by the user, but any data that is modified will still be saved.
I have some other stuff I will share with you soon aswell.
Gustaf Westerlund
CRM and SharePoint Consultant
Humandata AB
www.humandata.se
crmForm.all.xxx_myfield.Disabled = true;
Then any updates to the data of this field, will NOT be saved when the form is saved. There is a way to bypass this and this is to set the attribute to “Read only” instead, with the following javascript code:
crmForm.all.xxx_myfield.readOnly = true;
This will disable any editing of the field by the user, but any data that is modified will still be saved.
I have some other stuff I will share with you soon aswell.
Gustaf Westerlund
CRM and SharePoint Consultant
Humandata AB
www.humandata.se
Tuesday, April 17, 2007
Use url-parameters in javascripts in CRM
I had a look at Jonas Deibe's blog today (Jonas is the foremost CRM expert at Microsoft Sweden) and found an interesting tip I thought I'd tell you about.
He explains how to catch a url-parameter in the Javascript code, something I'd find very useful, especially if creating an integration with for instance SharePoint, since I can use this to control what is shown and what is not.
For instance, if you have a sharepoint integration with CRM where there is an IFRAME on the accounts showing the customer site in SharePoint, and the customer site shows the CRM account in an IFRAME also. It might be advisable to not show the IFRAME showing the sharepoint site, if it is shown in Sharepoint (=loop). Then you could use this technique to handle this.
It could also be used for shooting data into a CRM form from some other system. The URL-parameter could then be written to a specific field, it could even be saved and closed using the javascript command for that, in essence creating a very simple integration of data. Not very beautiful but still might be useful, since it is easy to create and very unobstrusive. Might be interesting if a program can't consume webservices for instance.
There are certainly a million other uses for this, so enjoy!
http://blogs.msdn.com/jonasd/archive/2007/04/16/render-hidden-values-in-tester-mode-by-using-querystring-parameters.aspx
Gustaf Westerlund
CRM and SharePoint Consultant
Humandata AB
www.humandata.se
He explains how to catch a url-parameter in the Javascript code, something I'd find very useful, especially if creating an integration with for instance SharePoint, since I can use this to control what is shown and what is not.
For instance, if you have a sharepoint integration with CRM where there is an IFRAME on the accounts showing the customer site in SharePoint, and the customer site shows the CRM account in an IFRAME also. It might be advisable to not show the IFRAME showing the sharepoint site, if it is shown in Sharepoint (=loop). Then you could use this technique to handle this.
It could also be used for shooting data into a CRM form from some other system. The URL-parameter could then be written to a specific field, it could even be saved and closed using the javascript command for that, in essence creating a very simple integration of data. Not very beautiful but still might be useful, since it is easy to create and very unobstrusive. Might be interesting if a program can't consume webservices for instance.
There are certainly a million other uses for this, so enjoy!
http://blogs.msdn.com/jonasd/archive/2007/04/16/render-hidden-values-in-tester-mode-by-using-querystring-parameters.aspx
Gustaf Westerlund
CRM and SharePoint Consultant
Humandata AB
www.humandata.se
Subscribe to:
Posts (Atom)