I talked a little bit about debugging Process Orchestration before. That was a good base, but a better understanding comes with time.

Here is what I understand now.

There are three processes involved with Process Orchestration:

• DBEventing – you see this in services
• Process Host Portal – you deploy this – it is a running website
• slxLogging – you can see this in task manager or proc mon

In my case we have a problem with the PO Portal not creating the files it should create at C:\Documents and Settings\All Users\Application Data\SalesLogix\Sync\QUEUEFiles . You should see a folder for each of your registered workflows (something with an entity name) AND a single XML file. If you do not it can mean that the Process Host portal is not running correctly.

When I run my process I get a .track file for each change I make that is being, well, tracked. In my case I am using the familiar division. So I have dbeventing running, I have browsed to registered processes in process host and I make a change to the database via the website. Track file gets created.

Shouldn’t there be a queue file?

There is a queue file created but the logging service picks it up so fast that the track file is all you can see. If you launch procmon from sys internals you can see that slx logging picks up the queue file and process it and then drops a track file.

It should be dropping it into your folder for your registered process, but in my case I do not have a registered process. I have yet to figure that one out.

When that happens the subscribers are notified (process Orchestration portal would normally be a registered subscriber) and it handles the track file.

So from the website a db change is made, then the add-on to the provider sees the change, looking for any changes it should watch for, a queue file is written, converted to a track and placed in each subscribers folder.

DB eventing looks for the queue files. slx logging service writes the track files and the queue files.

It is possible to retrieve data from SalesLogix web client using client side code. We have performed this task with Named Queries and SData both using jQuery to GET the data for us. This is not the easiest way and sometimes it is not the most ideal.

We are usually must more familiar writing server side code AND in an ASCX we start on the server anyway, so why not get the data from the entity there or write SData code on the server to retrieve our data? It is probably going to be easier and more familiar for most of us.

The reason why is because we need the data on the client ultimately. At some point to do charts or something else cool with a JavaScript Library you will need to get the data to JavaScript (the client).

So we want to write server side code to get data using SData, entity model or ADO.NET and spool out JavaScript.

How?

This is the easy part.

Get your javascript into a string of some sort.

Something like:

string s = "function sendmessage() {alert('here');}"

then write the code to actually send the javascript to the browser with the rest of the out put:

        ClientScript.RegisterClientScriptBlock(this.GetType(),"Chart JS",s,true);

This will get your code on the client and ready to be used by any other JavaScript on the page.

Where does this get us?

Well it tells us that we can write ANY JavaScript from the server side. So in the case of Ext js charts we can use this code to write data in the form that is needed by the charts. Just loop and format it properly and you are all set!

We are discussing this now for our Master’s Series class on Client Side Code in February.

To really get some client side validation in our pages we need to be able to stop postback. We already looked at how to get JavaScript in our pages but that only gets us so far.

We can write some JavaScript that will validate a form element, but the form will still submit! How can we stop that from happening?

Use return

Placing the word Return in front of your JavaScript call will tell the client that you want to actually listen for what the JavaScript function returns and either continue or stop based on that result.

So we change:

OnClientClick="cmdSave_ClientClick();

to:

OnClientClick="return cmdSave_ClientClick();

And edit our function to actually return true or false:

If you return false your form will NOT post. The one problem with this code is that if you return true your form will not post either…

So you need to handle the post yourself. Use firebug and get the actual ID of the button control (or other control that SHOULD be posting):
ctl00$MainContent$ProductDetails$cmdSave it should have $ in it not _ …

And add the following code when you actually want the form to post:

Of course your criteria for true and false is likely to be more complex, but we can get there.

To get started with a JavaScript library I suggest downloading one and giving it a try.

Let’s take Ext js. Download it here:

http://www.extjs.com/products/extjs/download.php

Extract the files to your IIS server or open the folder in Visual Studio as an existing web application. Browse to examples->Chart->charts.htm and press play. You cannot just double click this file and open in a browser. Go head and try – the flash player does not allow it. So run that page by right clicking it in VS.NET and view in browser.

Cool charts huh?

How did that happen?

Check out the source of the page. Look at the header.

  <!-- GC -->
 	<!-- LIBS -->
 	<script type="text/javascript" src="../../adapter/ext/ext-base.js"></script>
 	<!-- ENDLIBS -->
 
    <script type="text/javascript" src="../../ext-all.js"></script>
 
    <script type="text/javascript" src="charts.js"></script>

You can see that the page pulls in ext-base.jd and ext-all.js as well as a chart.js.

Chart.js just contains the actual data for the chart and the markup as well:

Ext.chart.Chart.CHART_URL = '../../resources/charts.swf';

Ext.onReady(function(){

    var store = new Ext.data.JsonStore({
        fields:['name', 'visits', 'views'],
        data: [
            {name:'Jul 07', visits: 245000, views: 3000000},
            {name:'Aug 07', visits: 240000, views: 3500000},
            {name:'Sep 07', visits: 355000, views: 4000000},
            {name:'Oct 07', visits: 375000, views: 4200000},
            {name:'Nov 07', visits: 490000, views: 4500000},
            {name:'Dec 07', visits: 495000, views: 5800000},
            {name:'Jan 08', visits: 520000, views: 6000000},
            {name:'Feb 08', visits: 620000, views: 7500000}
        ]
    });

    // extra extra simple
    new Ext.Panel({
        title: 'ExtJS.com Visits Trend, 2007/2008 (No styling)',
        renderTo: 'container',
        width:500,
        height:300,
        layout:'fit',

        items: {
            xtype: 'linechart',
            store: store,
            xField: 'name',
            yField: 'visits',
			listeners: {
				itemclick: function(o){
					var rec = store.getAt(o.index);
					Ext.example.msg('Item Selected', 'You chose {0}.', rec.get('name'));
				}
			}
        }
    });

Complex stuff at first glance, but first look at the data and then match up the items with the extjs markup.

Edit the data. Change the datanames. play around with it a bit and break it.
As always be sure to attend the Client Side Coding Master’s Series class.

SalesLogix uses a few JavaScript Libraries by default in their product. Let’s talk about what a JavaScript Library is first.

A javascript library takes some of the more complex and mundane parts of writing JavaScript and makes them easier and faster for the developer. It will usually also take all of the cross platform code that you would have ended up writing and makes it “go away”.

Cross platform?

Yeah IE and FireFox have never really agreed on how JavaScript should be written. It is really the rendering engine used in each that differs, but overall FireFox is MORE compliant with standards and IE is less. This is becoming less and less true and with HTML 5 we all dream this will go away, but in the real world we still have users running IE 6.0! IE 6.0 is an evil browser for a JavaScript programmer.

So you end up writing code that checks for document.layers or document.all and writing your FireFox code in one and IE code in the other.

This is all (mostly) a thing of the past with the various JS libraries out there.

What Libraries are out there?

SalesLogix uses three main libraries:

1. jQuery
2. EXTjs
3. YUI

But there are many more out there.

The Developer, Admin, End User subscription page uses DOJO and Prototype is a very popular library as well.

Explore, try and see what you can do. It is VERY easy compared to years past, but still more complex than most code you write today.

Now that we know that we are working with JavaScript — how can we actually make use of it inside the SalesLogix Web Client?

onclientclick()

Most controls have an onclientclick or equivilant that you can take advantage of.

OnClientClick=”cmdSave_ClientClick();

is a simple example.

This is accessed through Application Architect here:

In the screenshot I show “anything(“sasd”)” because there is a known issue with this actually writing code for you. But that isn’t a big deal.

So it is that simple.

You end up with the following code at the bottom of your ascx page. Go look!

We are preparing for our Client Side Coding Master’s Series class in February. During this process we tend to talk to a lot of people about the class and get some insight into what is misunderstood and what needs to be explored in the class. I have had some interesting conversations inside and outside of Sage. This seems to be an area that can use some explanation.

What is client side code?

Client side code is anything that runs in the browser. We are talking about SalesLogix web here, so this is anything running on the users machine in the browser — usually IE or FireFox. In most cases client side code is JavaScript.

What is the big deal with Client Side Code?

Most of the “waiting” you do on any web page is for the server to process the code of the page. It can also be for data retrieval and for actually sending the data to your browser as well. With client side code you turn that code into something that can be run on the client (remember client means browser – Firefox or IE in most cases). This means that the server has less of a load and you generally do not need to wait for the data to go back to the server and then back to you (commonly referred to as “post back”) to see your changes.

How does AJAX fit in then?

AJAX is Asynchronous JavaScript and XML. So it fits in as client side code, but that particular use of the technology allows you to click a button for instance and see a result without the whole screen refreshing. This is done with HTTP (web) requests through JavaScript. The data passed back and forth is generally XML, but it honestly can be any format JSON is a good one too.

AJAX is a bit complex at this moment, so lets just say we will get there in the class (if you made it to the SData Master’s series class I used AJAX in my SDataJavaScriptExample a lot). We are worried about the basics here.

So what do I need to know?

JavaScript runs on the client.
The client is your browser.
JavaScript is generally faster than server side post backs.
It also provides a really clean interface and user experience.