Here is the associated test class. One thing I really dig about the SF development model is the integration with unit tests. This almost makes up for the suckiness of the IDE.

I might as well make a few comments about the development process. First of all, the unit test integration is rather nice. They will automatically “sandbox” your database for the unit test and give you a coverage report. A few things to watch out for:

• Keep your eye on the “Problems” tab. If there is an error, maybe in some other file, the IDE will still happily run the previous version of your tests and you’ll be left wondering why your changes are not taking effect. Happened to me more than once.
• Use a sandbox for development – very little can be done in a production environment because you need test coverage to deploy the code, and you can’t test the code until it’s deployed.
• The Force.com IDE sucks really, really bad. I don’t have anything against Eclipse – I love Eclipse for Java code! But writing Apex code is very, very primitive. The build operations are quite slow (not “SalesLogix App Architect” slow, mind you, but still slow) and the errors reported are not clear. Intellisense very rarely works. Stuff occasionally gets out of sync and has to be blown away and resynced from server. Also, only a few items can actually be done from the IDE, the rest has to be configured using the web interface which is very cluttered and confusing. The only redeeming factors are the documentation which is top notch (both the reference guide and the community) and the unit test integration.

An alternative to be aware of is that the processing can be done remotely and use the bulk update API to do the communication with the database. In retrospect it might have been the way to go in this scenario, since I already had to do some processing in a remote app, but this was a good project to tour the Apex facilities with so I am glad I got the chance to do that.

I also used Heroku for the remote processing part, this was my first non-toy app on that platform, and a very positive experience so far.

For an intranet scenario, where we can be certain that most users will be using Outlook and IE, I came up with the following solution. It will attempt to send the mail using Outlook automation and fall back to a “mailto” method if not available (i.e. either they are using another browser / OS, or they don’t have the correct security settings). It is a CommonJS module, I have started using RequireJS for custom modules to prevent namespace clashes.

The tricky part was making sure the URL stayed short enough – if it gets over a certain length, Firefox will just ignore it altogether (other browser will truncate it). This is the job of the addUrlComponents function. I call it with the recipient, subject and body parameters until the length is exhausted, but each is limited – this way if there is a ton of recipients, rather than trying to keep them all and getting a blank email, it limits the total address length to 900 characters and saves the rest for the email itself. It’s not ideal either way but I figured this was preferable.

I went ahead and created a test page for it since the addUrlComponents function was not trivial… this also gave me a good occasion to use qunit – very, very easy to get running with that test framework.

PS – this gist thing is a great way to get syntax highlighting on the cheap hah!

First of all note that if you have a lengthy process you will need to configure the request timeout in the web.config. It would be something like (assuming your page is called Import.aspx):

<location path="Import.aspx">
  <system.web>
    <httpRuntime executionTimeout="3600" />
  </system.web>
</location>

Also, do take a look at the note on potential performance problems, at the end of this post.

Now, a quick review of the options:

• There is a progress bar control called RadProgressManager which is actually included as part of SalesLogix (they use it in the lead import screen). It works relatively well once you have it configured properly but I have found a few challenges when trying to use it. First of all, it works by polling, which means it makes repeated requests to the page to find out the progress – this is relatively inefficient, though usually not a big concern. Secondly, the control takes some work to properly configure – it is rather sensitive to the order in which components are loaded, where it is placed respectively to the update panels, whether the postback is asynchronous or not, etc. If everything is not “just right” it will fail, often with an obscure error message (or no message at all). Thirdly, the default look is absolutely hideous, so you usually have to replace the whole thing with a custom template – quite a bit of work. Finally it gives little options other than just reporting a progress percentage and a step description, so if you want to for example report errors as they happen you may be out of luck. For these reasons I have not used it very often.
• One other way is doing repeated refresh of the page (or just the update panel that contains the progress bar) to refresh the status. This works pretty well if the processing happens on a separate service (other than being inefficient as it requires a reload every time) but not if it is done on the same page of course as it would not be able to reload itself until the process was finished! Note that you can’t do the process on a handler and refresh the page either, as a page in SalesLogix always requires an exclusive access to the session.
• Finally there is an option recently called “pushlet” but which was already used years ago before Javascript even came of age. The idea is to post the data to the page which does the process, but instead of reporting the process “out of band” it just writes it out as it happens. Now, the idea is that instead of just writing the process to a blank screen, this page outputs a snippet of Javascript which gets executed and (via the method of your choosing) reports a progress or an error. The advantages are that it uses only one connection unlike the previous 2, reports the progress in real-time (unlike the other ones which will have a lag imposed by the polling rate), offers complete control of the UI, and is rather easy to implement, even more so if the UI is driven mostly from Javascript.

So, the basic concept of the “pushlet” is to post the form’s data into a hidden iframe. This can be done either by setting the SRC of the iframe (if no post data is required), by stuffing the form’s data into a form on the iframe itself and posting it, or by setting the TARGET of the current page’s form and posting it. The last one is most powerful as it will let you post files, but unfortunately also a bit more complex as you have to fight with ASP.NET to obtain a reference to the form and make sure you don’t interfere with the rest of the page. Here is a post that describes it though, and by a happy coincidence was posted right after I finished this one: Changing an HTML Form’s Target with jQuery – it’s for a vanilla ASP.NET scenario but should mostly apply to SalesLogix as well. An example of the second method, which works well enough as long as there is no need to upload a file:

var root = document.getElementById("bulkRequestSubmitFrame");
var rootDoc = root.contentDocument || root.contentWindow.document;
var baseUrl = location.href.replace(new RegExp("/[^/]*$"), "");
var url =  baseUrl + "/SmartParts/LitRequest/LitRequestBulkSubmit.ashx";
var scriptParts = [];
var doc = rootDoc.createDocumentFragment();
function createElement(tagName, attrs) {
	var elem = document.createElement(tagName);
	for (var a in attrs) {
		elem[a] = attrs[a];
	}
	return elem;
}

// this is the actual form data
doc.appendChild(createElement("input", { name: 'submission', value: Ext.util.JSON.encode(submission) }));
doc.appendChild(createElement("input", { name: 'itemSelection', value: Ext.util.JSON.encode(itemSelection) }));

rootDoc.body.innerHTML = "<form id='theform' action='" + url + "' method='POST'></form>";
var form = rootDoc.getElementById('theform');
form.appendChild(doc);
form.submit();

As the handler for the form processes the data, it will output snippets of javascript, such as:

<script type="text/javascript">
parent.reportSubmissionProgress(50);
</script>

Or to report an error:

<script type="text/javascript>
parent.reportSubmissionError("Unable to process contact id XYZ");
</script>

And the final piece on the client side is how to report the progress – this is made easy by the fact that ExtJS includes a decent-looking progress bar:

• To initialize it:

_percent = 0;
_errorText = "";
_progressText = "Contacting server...";
_progress = Ext.MessageBox.show({
  title: "Sync Progress",
  width: $(window).width() * .6,
  progress: true,
  progressText: _progressText
});

• To report progress:

function reportSubmissionProgress(percent, description){
  _percent = percent / 100;  // Ext % goes from 0 to 1
  _progressText = description;
  Ext.MessageBox.updateProgress(percent, description);
}

• To report an error:

function reportSubmissionError(error){
  _errorText += (error + "");
  Ext.MessageBox.updateProgress(_percent, _progressText, _errorText);
}

• And finally to hide it:

function reportSubmissionComplete() {
  Ext.MessageBox.hide();
}
// this will ensure the progress bar gets hidden once the iframe finishes loading
document.getElementById("bulkRequestSubmitFrame").onload = reportSubmissionComplete;

It looks like this:



The last piece of the puzzle is the handler on the server side, but this is also the easiest one. You can use a generic ASP.NET handler (ASHX) and just make sure you turn off buffering (context.Response.Buffer = false) and set an HTML content type (context.Response.ContentType = “text/html”) then use context.Response.Write to report the progress… to test it out, try something like:

public class TestHandler : IHttpHandler, IReadOnlySessionState
{
  public bool IsReusable { get { return false; } }
  public void ProcessRequest(HttpContext context) {
    context.Response.ContentType = "text/html";
    context.Response.Buffer = false;
    for(int i=0; i < 100; i++){
      context.Response.Write(String.Format(@"<script type='text/javascript'>
          parent.reportSubmissionProgress({0}, 'Reporting progress {0}...');
      </script>", i));
      Thread.Sleep(300);
    }
    context.Response.Write(@"<script type='text/javascript'>
         parent.reportSubmissionComplete();
      </script>");
  }
}

That's about it. It ends up being a good fit if you already have some javascript to drive some of the UI on your page. It's quite flexible and the way it works makes it easy to understand and troubleshoot using a tool like Fiddler or Firebug.

Remember that if the process is really lengthy, or if it is likely that many people will be doing it at the same time, you'll want to do that outside of the web client, because it will consume an ASP.NET thread and a connection handle as long as that connection is open. Then you have to use a separate service and use a polling mechanism to check on the progress, otherwise your server will grind to a halt as all its processes are stuck serving users - FYI, yes, this is based on first-hand experience. I recommend reading Improving ASP.NET Performance on the Microsoft P&P site, especially the section on threading (the whole thing is worth a read though).

]]> http://blog.nicocrm.com/2011/01/29/enhancing-a-lengthy-process-with-a-progress-bar/feed/ 1 http://blog.nicocrm.com/2011/01/19/tracking-changes-in-related-saleslogix-entities/ http://blog.nicocrm.com/2011/01/19/tracking-changes-in-related-saleslogix-entities/#comments Thu, 20 Jan 2011 04:42:48 +0000 Nicolas Galler http://blog.nicocrm.com/?p=459 I have been doing a bit of exploration via trial and error and wanted to post my findings here. Note all of those were found on SLX 7.5.2.

Say you want to audit changes in an entity related to the main entity of your form… for example in my case ticket.Contact (the customer can edit the contact’s first name from the ticket screen), or this would probably work the same with the address control on the account main view. You may run in the following issues:

• If you don’t make any change to the main entity itself, its Update event will not get called.
• The Update event of the related entity will not get called
• When you try to retrieve the changes for the related entity, you can’t simply do “((IChangedState)ticket.Contact).GetChangedState()” – this will return an empty change set. Instead you have to go through the member changes of the main entity.

Not much can be done about the first 2 items unfortunately – the event is just not getting triggered. This means you have to call the method to track the changes from the application code unfortunately for the time being (hopefully it will get fixed soon since it creates a pretty big hole in sdata applications – I have not tested to see if it was on 7.5.3). In the meantime let me elaborate on the last point. The main entity (e.g. ticket) keeps tracks of changes to related entities in its own ChangeSet. To retrieve changes on one of those linked entity you can use the Find() method of the ChangeSet to retrieve an EntityChange object. For some reason it does not allow one to retrieve this EntityChange using the property name (such as what you might use for FindPropertyChange or FindMemberChange ), but since you already know the id and it will be unique you can just use something like

EntityChange customerChange = changes.Find(x =>
          (String)x.ChangedEntity.EntityId == (String)ticket.Contact.Id);
if (customerChange == null)
    return;

From there, retrieve a ChangeSet using customerChange.ChangedEntity.EntityChanges, and you can manipulate that one like a regular ChangeSet:

ChangeSet changes = customerChange.ChangedEntity.EntityChanges;
PropertyChange nameChange = changes.FindPropertyChange("FirstName");

For a more deeply linked entity like ticket.Contact.Address it is also retrieved from the ticket entity’s ChangeSet:

EntityChange addressChange = changes.Find(x =>
    (String)x.ChangedEntity.EntityId == (String)ticket.Contact.Address.Id);

Hope this helps!

]]> http://blog.nicocrm.com/2011/01/19/tracking-changes-in-related-saleslogix-entities/feed/ 0 http://blog.nicocrm.com/2011/01/06/confirmation-prompt-in-saleslogix-web/ http://blog.nicocrm.com/2011/01/06/confirmation-prompt-in-saleslogix-web/#comments Thu, 06 Jan 2011 19:30:32 +0000 Nicolas Galler http://blog.nicocrm.com/?p=448 A lot of time in the LAN client I have some logic similar to this snippet (which updates the account manager to match the region selected by user in a picklist):

sUser = GetField("userid", "userinfo", "region = '" & Sender.Text & "'")
If sUser <> lueAccMgr.LookupID Then
  If MsgBox("Would you like to change the account manager to match selected region?", vbOkCancel) = vbOk Then
   lueAccMgr.LookupID = sUser
  End If
End If

In the web client you would want to do something like this:

IUser user = GetUserByRegion(CurrentEntity.Region);
if(user != CurrentEntity.AccountManager){
  if(PromptUserForConfirmation()){
    CurrentEntity.AccountManager = user;
  }
}

But how to implement the “PromptUserForConfirmation” method? You can’t do a modal dialog box from server-side code.

One method would be to implement all of the logic from client side. You can use an ajax call (maybe using sdata) to implement the “GetUserByRegion” in Javascript, and probably in this particular case it would be simple enough to be very feasible.

Sometimes there is a bit too much logic on the server side to be ported over to javascript, or you just don’t want to have to load too much logic on the client (which is often harder to maintain). In that case you can use what I call the “hidden button” trick. This keeps most of the logic on the server and separate the process in 2 steps, using a non-displayed button on the client to allow the script to “resume”. The button on the page would be something like (make sure you do “display: none”, not “Visible=false”, as the latter would prevent the button from being output on the page at all):

<asp:Button style="display:none" runat="server" id="btnConfirmRegionManagerChange" OnClick="btnConfirmRegionManagerChange_Click"/>

The code on the picklist change event would become:

// first postback, executes when the user has just made the picklist change
// (assuming the picklist is set up to autopostback)
// here we run the first part of the logic
IUser user = GetUserByRegion(CurrentEntity.Region);
if(user != CurrentEntity.AccountManager){
  // register a client script to show confirmation prompt and simulate a button click
  ScriptManager.RegisterStartupScript(this, GetType(), Guid.NewGuid().ToString(),
   "if(confirm('Would you like to change the account manager to match selected region?')) " +
     "$('#" + btnConfirmRegionManagerChange.ClientID + "').click();", true);
}

And finally the handler for the btnConfirmRegionManagerChange click would take care of the second part of the process:

// Here we just call the GetUserByRegion method again...
// If there was a lot of processing involved you could cache the result from the previous postback
// into a hidden field or a ViewState variable
IUser user = GetUserByRegion(CurrentEntity.Region);
CurrentEntity.AccountManager = user;

This way you have a bit of extra work, but the basic structure of the code remains the same so it is still easy to follow. I should mention I have not actually tried the code snippets above so if you copy / paste and find any typo please let me know.

Hope this helps!

]]> http://blog.nicocrm.com/2011/01/06/confirmation-prompt-in-saleslogix-web/feed/ 0 http://blog.nicocrm.com/2010/12/05/ad-hoc-rest-services-on-the-force-com-platform/ http://blog.nicocrm.com/2010/12/05/ad-hoc-rest-services-on-the-force-com-platform/#comments Sun, 05 Dec 2010 20:31:49 +0000 Nicolas Galler http://blog.nicocrm.com/?p=428 Note – as of Summer ’11 there is a much better solution in the form of Javascript Remoting. I am leaving the information below for reference but do not recommend using it.




Force.com is coming up with a REST style api to access the data from 3rd party applications, widgets etc. While this is great news as this type of web services is a lot easier to access than traditional SOAP calls from many programming languages (including obviously the important Javascript), it should not be forgotten that it has been possible for a while already to create your own, custom REST-style services – very useful when trying to make a page more responsive by coding certain areas in Javascript with AJAX calls. These don’t benefit from the OAuth authentication so they are more useful for pages that are accessed by already authenticated users. One advantage is that as they are very specialized you can make the payload as lean as necessary. One drawback is that as the facilities of the native Force.com programming environment are a bit rudimentary there is a certain amount of boiler-plate code involved.

The controller side looks like a usual controller, typically using the query-string or form parameters in the constructor to build a result which is then available to the view. The view can loop over that result and output it in JSON format using the built-in JsEncode function. For example here is a simple contact search service:

public with sharing class SearchServiceController {
	/**
	 * Array containing the results.
	 */
	public Contact[] Matches { get; private set; }

        /*
         * grab the parameter from the page's and run the search.
         */
        public void executeSearch() {
		String name = ApexPages.currentPage().getParameters().get('name');
		executeSearch(name);
        }

	/**
	 * Run the search with the specified parameters, populating the Matches variable.
	 */
	public void executeSearch(String name){
		Matches = [select Id, Name, MailingStreet, MailingCity, Mailing State from Contact where LastName=:name];
        }
}

Then the view could look something like this… most modern programming languages have constructs for automatically serializing to JSON nowadays, but not Apex – still, it’s not that hard to get the same result on the view:

<apex:page contentType="text/javascript" controller="ProximitySearchServiceController" action="{!executeSearch}" >
<apex:variable var="rowIndex" value="{!0}"/>
{"result":[
    <apex:repeat value="{!Matches}" var="contact" >
        <apex:outputText rendered="{!rowIndex != 0}" value=","/>
        {"name":"{!JsEncode(contact.Name)}",
         "address1":"{!JsEncode(contact.MailingStreet)}",
         "city":"{!JsEncode(contact.MailingCity)}",
         "state":"{!JsEncode(contact.MailingState)}" }
         <apex:variable var="rowIndex" value="{!rowIndex+1}"/>
    </apex:repeat>
]}
</apex:page>

Not exactly rocket science, but that’s kind of the point: the beauty of REST is that it simply leverages the existing HTTP protocol without the added baggage (both in payload and complexity) of an RPC protocol. Perhaps the only tricky part in the force.com version is the output of the comma in the right position (remember a trailing comma in a list works fine in FireFox but not in IE). There is no out of the box facility for getting the row index in the repeater. Also, don’t forget to set the contentType so that the default page headers don’t get included. And don’t forget to disable the development mode on the page… other, the HTML for the page editor will still get sent and mess with the JSON output!

Lastly a little security note… such services are not wide open because they require the user to be logged into Salesforce. However, it is possible for an attacker who controls a web site that is visited by a Salesforce user to submit a request on their behalf (including their authentication cookies). They won’t be able to retrieve the results, but if the service causes an update or an insert that could happen. If it’s a concern (e.g. for an ordering system) you can check the HTTP referer using ApexPages.currentPage().getHeaders().get(‘Referer’), and make sure it comes from an expected site / page. Some good notes about that on the force.com blog.

]]> http://blog.nicocrm.com/2010/12/05/ad-hoc-rest-services-on-the-force-com-platform/feed/ 0 http://blog.nicocrm.com/2010/12/05/misadventures-with-the-dojo-build-system/ http://blog.nicocrm.com/2010/12/05/misadventures-with-the-dojo-build-system/#comments Sun, 05 Dec 2010 16:00:05 +0000 Nicolas Galler http://blog.nicocrm.com/?p=419 Dojo has this amazing tool as part of their framework which is kind of a all-in-one shop for all your Javascript and CSS optimization needs. It’s called the Dojo Build System. It uses the dojo.require statements that are part of the module definition to figure out the combination of Javascript files that will include everything needed, but not more, to minimize both the total size of data transferred and the number of connections necessary to do so.

Overall it works great and there are a few good examples that show how to use it as part of their documentation. I did run into a few pitfalls mostly due to the assumption it makes about the directory layout which I thought I should document here for the benefit of Google and Nick-from-the-future.

1. Although not mentioned explicitly, if you specify a CSS optimization level, the tool will optimize all CSS files it finds in the folder. I spent a while looking for a switch that would let me specify which CSS files to pick up before realizing that.
2. A little catch: the output of the Javascript optimization is to be found under the “release/dojo” folder, not “release/yourmodule” as you might expect.
3. It is quite sensitive to syntax errors and the error messages are really not very good… so make sure the Javascript in the files is all good… especially when you also take into account the fact that the tool takes a while to run because it re-processes the whole Dojo distribution every time (I wish there was a way to do an incremental build but I have not figured out how).
4. The tool must be run from within the correct folder (util/buildscripts in the dojo source distro). Most of the examples in the documentation have you place your module folder (or create a symlink to it) within the dojo source folder… this is pretty messy and confusing, and makes the upgrade of dojo harder because if you pick up a new release you have to remember to create the appropriate symlinks. There is however an example directory layout that works well and keeps things separated on DojoCampus. They also provide a sample shell script there that makes invoking the tool a lot easier. It is also good to show the various important parameters for the build.
5. Along the same lines: be careful with symlink, as the tool does a lot of “..” to get to the various files… so if the folder is a symlink the tool might walk itself out of the directory structure.
6. Even once the Javascript file is flattened, one thing to remember is the localization messages are still loaded separately (the assumption is that the system won’t know what language to load until runtime). If desired (if only one language is needed) it can be concatenated to the output file, and then the locale can be fixed in the djConfig parameter.
7. Finally, an error that I spent quite a while to debug: if the “releaseDir” contains a “..” in its path, then the build errors out with:

   js: "./jslib/i18nUtil.js#61(eval)", line 1: uncaught JavaScript runtime exception: SyntaxError: missing name after . operator
   
   js: dijit..var.www.nicocrm.test.spx....spxRelease.release.dijit._editor
   

   Oh well, now I know. Apparently there is a similar bug misfeature if you include a backslash on the path name (if you do the build on Windows). I can’t speak for that one for sure as I only tried it on Linux so far.

Once I got past those problems all was good – inline CSS and Javascript, inline templates, all comments stripped, and the Javascript is compressed. You should only need 2 scripts included per page: the “base” dojo.js which is normally included on every page thus will be cached, and the “layer” script which is created based on the modules that are needed on that specific page. For CSS you might have 3 files: the base dojo.css, the theme, and the layer file (I suppose you might combine the theme and base dojo stylesheets, for an even more optimized build). Unfortunately however the tool does not appear to do CSS sprite optimization yet.

]]> http://blog.nicocrm.com/2010/12/05/misadventures-with-the-dojo-build-system/feed/ 2 http://blog.nicocrm.com/2010/11/21/free-amazon-ec2-instance/ http://blog.nicocrm.com/2010/11/21/free-amazon-ec2-instance/#comments Sun, 21 Nov 2010 18:38:11 +0000 Nicolas Galler http://blog.nicocrm.com/?p=412 Throwing it out there as I did not know about it – Amazon is offering a free tier for its Elastic Cloud services. It’s available at http://aws.amazon.com/free. Only for the Linux “micro” instance, and only for a year, but it’s still very nice for me (mainly so I can avoid problems like waiting for 2 weeks for a new fan). The one thing that I found was rather dumb is I had to create a new account for it as it was reserved to new users and I had previously used Amazon S3 on my main account (why ever do people make these “new customers only” offers – are they really trying to alienate the existing customer base?). Also be careful not to make the same mistake I made – this pricing only applies to the “basic” Linux install, not the Suse or CentOS builds.

Also not sure when they added the Windows “Micro” instance – not part of this free tier but at $.03/hr that would be very economic way to run a small site if you need a bit more control than with an ASP.NET host (no, I very much doubt you can run SalesLogix on it, hah). It comes off quite a bit cheaper than MS Azure and I am not too sure what Azure buys you for the extra cost. Will be an interesting competition to watch in the coming months.

]]> http://blog.nicocrm.com/2010/11/21/free-amazon-ec2-instance/feed/ 0 http://blog.nicocrm.com/2010/10/17/check-your-relations/ http://blog.nicocrm.com/2010/10/17/check-your-relations/#comments Sun, 17 Oct 2010 19:44:39 +0000 Nicolas Galler http://blog.nicocrm.com/2010/10/17/check-your-relations/ A familiar problem with upgrades from SalesLogix LAN to Web is many of the foreign keys may have some invalid values.  The legacy LAN client allowed one to put basically anything in there without much validation since we were playing with raw SQL, but the NHibernate platform used in the new client is not as forgiving.  Therefore you may find yourself with this type of errors:

System.Web.HttpUnhandledException: Exception of type ‘System.Web.HttpUnhandledException’ was thrown. —> System.Reflection.TargetInvocationException: Property accessor ‘Ticket’ on object ‘Sage.SalesLogix.Entities.TLXProjectExpense’ threw the following exception:’No row with the given identifier exists[Sage.SalesLogix.Entities.Ticket#            ]‘ —> NHibernate.ObjectNotFoundException: No row with the given identifier exists[Sage.SalesLogix.Entities.Ticket#            ]

What happened here is the original developer chose an empty string instead of a NULL to indicate the absence of a value – it works fine on the LAN client but the web client tries to actually load a ticket with an id of “            “.  The solution recommended so far is to clean out those values as you find them… obviously not very practical in an upgrade where you could have dozens of foreign key relationships to check one by one.

Thankfully all the information we need to get around the problem is already stored by SalesLogix and collected in the entity model – so all we have to do in theory is crawl through the relationships defined in the App Architect and run an update for each one of them.  It is actually quite easy as Sage prepared some neat (albeit undocumented) API to examine the model metadata.  For example this is the code I used to load the project model and iterate through the relationships:

IProject project = ProjectUtility.InitProject(ModelPath);
OrmModel model = project.Models.Get<OrmModel>();
foreach (OrmRelationship relationship in model.Relationships)
{
  // ...
}

It took me a few hours to write the app, mostly because I had set out to learn a few more things about WPF at the same time – the logic for the check and update itself was pretty easy. The one caveat is there are a few relationships that are a bit “odd” and can’t get fixed right (for example the M:1 relationship from targetresponse to MKTGSVC_RECIPIENT is on TargetResponseId which we can’t null out)

For now it is usable as a standalone app… Eventually I would like to make it as an App Architect extension and add a few features (most importantly the ability to drill down to see the actual data for the invalid records)



For the source code I made it available as part of the OpenSlx project on GitHub, but the binaries can be downloaded here if you want to give it a try (obviously be sure to backup the DB beforehand etc – the “no warranty” disclaimer is there for a reason!) One big caveat there before I forget – if you have problems with invalid Seccodeid in the Secrights table, etc, you may have to do some cleanup before and/or after running the script as it will null them out which will crash the client.

]]> http://blog.nicocrm.com/2010/10/17/check-your-relations/feed/ 0