I really want to create some dependent datagrids using the SalesLogix Web client. Well it is not that I want to do so, but a Partner asked and I thought it was a neat customization. It turns out it has already been documented here, but that didn’t exactly work without modifications for me.

So I went a bit further. Rich provided some really good tips and some good code.
Things like:

• The second datagrid will get its datasource from a false getbymethod
• The code to dynamically load the second datagrid from the first will go in the OnRowSelected event
• Here is the iCriteria code you need

Which was all spot on and worked well for him. I took it a slightly different route which required some changes. Let’s see if I can explain.

The scenario

First, this is all documented in video format and the bundle is available via the developers subscription.

I wanted to use Projects as the basis for my customization. Really the partner wanted to use Project as the basis, so that is what I did. Remember that in the SalesLogix database there is already a table called “Projects.” In Application Architect I right clicked my Application Entities node and created an entity based on an existing table and left it at that. I then created my two new entities: projectstages and projecttasks. Projectstages is a child of projects and projecttasks is a child of stages. Joins were created as needed too.

Create the grids

The real trick is the Project entity is where the page will be created. It will have one datagrid for stages bound to a datasource based off of its projectstages property (the relationship). No big deal. Plenty of stuff in the videos for that.

The next datagrid was harder. It will be loaded on the selectedrowchange event of the other datagrid. So how can I get Application Architect to allow me to compile? That is where Rich’s other suggestion comes into play.
Create a business rule on the project entity that returns an empty iList of projecttasks:

Then you simply create a datasource based on that method (we do this a lot in classes and other examples, it is commonly called the getbymethod). You bind your datagrid to that datasource and now you can select the fields from the projecttask entity to display. This helps later when you really fill up the datagrid with some data — it will know which fields to show.

OnRowSelected

So now the code on the OnRowSelected Event:

int rowindex = myGrid.SelectedIndex;
foreach (System.Collections.DictionaryEntry val in myGrid.DataKeys[rowindex].Values)
{
if (val.Key.ToString() == "Id")
{
Sage.Platform.Repository.IRepository pt =
Sage.Platform.EntityFactory.GetRepository();
Sage.Platform.Repository.IQueryable qry = (Sage.Platform.Repository.IQueryable)pt;
Sage.Platform.Repository.IExpressionFactory ef = qry.GetExpressionFactory();
Sage.Platform.Repository.ICriteria criteria = qry.CreateCriteria();
criteria.Add(ef.Eq("PROJECTSTAGEId", val.Value.ToString() ));
System.Web.UI.WebControls.GridView myChildGrid =
(System.Web.UI.WebControls.GridView)form.dgTasks.NativeControl;
myChildGrid.DataSource = (criteria.List());
myChildGrid.DataBind();
}
}


You can see it is pretty much the code we used for our iCriteria Examples here and here and here.

The code that may change when sp2 is released is here:

System.Web.UI.WebControls.GridView myGrid =
(System.Web.UI.WebControls.GridView)form.grdPROJECTSTAGES.NativeControl;


What I am doing here is taking the control from the form that is passed in and casting it into its asp.net equivalent. I do this because the SalesLogix Datgrid does not expose the .SelectedIndex property and later on I do it again for a another property and a method:

System.Web.UI.WebControls.GridView myChildGrid =
(System.Web.UI.WebControls.GridView)form.dgTasks.NativeControl;
myChildGrid.DataSource = (criteria.List());
myChildGrid.DataBind();

The real key to the code is that the second datagrid expects a list of ProjectTasks. I provided that initially with my fake business rule and now I am doing it with:

myChildGrid.DataSource = (criteria.List());

Cool? Comments? Suggestions? Can you do it?

I was asked recently about when to use custom properties. The question came from a situation where the Age for the Contact was to be displayed on a quickform. My approach would be to add Age as a custom property in the Application Architect. I would avoid storing any calculated fields in the database, mainly for data integrity reasons – what happens when you need to update the value in the Age field (i.e. a year has passed and the person is a year older)? Custom Properties are appropriate when you need a field that is determined by a calculation or when you want to concatenate certain fields or apply formatting.

Using a Custom Property in Application Architect would accomplish what we want by having the Age value available but also making it dynamic(its calculated so no need to update the next year). You could also use a calculated field setup in the SLX Administrator but we will focus on a Custom Property. The results would be a Custom Property listed under your Entity Properties that can be used like a regular property on forms, in code etc. Custom Properties are read-only.

Here is the results in the UI displaying the Age. The Age textbox is ReadOnly, the Age value would change automatically if the BirthDate was changed (when the user clicks save).

First you would create a new Custom Property off of your Entity. Right Click your entity and choose ‘New Code Snippet Property’. We will set the Custom Property name to Age and the return type to Int32.

Then we will add a Step and choose C# for the code snippet.

public static void GetAgeStep( IContact contact, out System.Int32 result)
{
// TODO: Complete business rule implementation
DateTime curDateTime = System.DateTime.UtcNow;
DateTime birthdate = (DateTime)contact.Birthday;
TimeSpan tsAge = curDateTime.Subtract(birthdate);
DateTime dtAge = new DateTime(tsAge.Ticks);
int intAgeYear=dtAge.Year-1;

result = (int)intAgeYear;
}

In the code we first get the current date. Then we get the contact’s birthdate. We can get the contact’s birth date from the contact entity that is passed into the custom property. See the signature and how IContact is passed right in…
public static void GetAgeStep( IContact contact, out System.Int32 result)
We then calculate the Age of the person by subtracting the two dates and then getting the year from the subtracted date result. The cool thing to note is that you can pretty much to anything in your Custom Property… I could update another Entity.Property, lookup a value from another Entity (or the current Entity), I could even do an Entity.Save() or Entity.Delete()

Finally, after doing a Build Interfaces you can then use the Custom Property as a Entity.Property on your quickform – or even in a BusinessRule or any other location where you have access to the Entity.

You would think that working with checkboxes is pretty easy and straight forward on the Web right? We you would be right and you would probably be missing one or two caveats.

The steps

First — this was covered in the developers subscription already, so if you do not have the developers subscription, please check there after reading this post. I would search for “checkbox” myself :)

First create the field

I used the opportunity table and created the field using database manager. You can see the new field in the database in the screenshot. I told db manager that I wanted a new field, called it “confident” and told it I wanted the type to be SLXBoolean.

Now go into Application Architect and update the entity

Just right-click the entity, and update. Notice the field is already there at the bottom; but when you add it, it is added as “text”. We need to update this to slxBoolean, or on the Web: “TrueFalse”

Finally, add the field and bind it

Just right-click on the form you want to add the checkbox on and insert a checkbox. Edit the DataBindings so that the new field is tied to the checked property. If you missed the last step, you will get an error on the Web.

That is it. It is that simple to add a checkbox for a form in SalesLogix Web. It should be that easy, but I think the missed step is updating the type to “TrueFalse”. Like all good SalesLogix Developers you only need to be told once — and now you have been.

Go into it a bit more

Here is what happened when you deployed:

<div class="slxlabel alignleft checkbox">
<SalesLogix:SLXCheckBox runat="server" ID="chkConfident" CssClass="checkbox "
Text="<%$ resources: chkConfident.Caption %>" TextAlign="left" ToolTip="<%$ resources: chkConfident.ToolTip %>" AccessKey="I" />
</div>

Which gets the control on the form and sets its text and its tooltip (I set these properties in AA).

And then the binding:
protected override void OnAddEntityBindings() {
// txtDescription.Text Binding
Sage.Platform.WebPortal.Binding.WebEntityBinding txtDescriptionTextBinding = new Sage.Platform.WebPortal.Binding.WebEntityBinding("Description", txtDescription, "Text");
BindingSource.Bindings.Add(txtDescriptionTextBinding);
//SNIP *******
// chkConfident.Checked Binding
Sage.Platform.WebPortal.Binding.WebEntityBinding chkConfidentCheckedBinding = new Sage.Platform.WebPortal.Binding.WebEntityBinding("ConfIdent", chkConfident, "Checked");
BindingSource.Bindings.Add(chkConfidentCheckedBinding);

//etc****


That’s it.

I was recently asked how to default a value in a Lookup. This is not difficult to do at all, but the first approach is usually to put the default value in the lookup control itself. Actually, the best approach is to put the default value into the entity.property associated with or bound to that Lookup.

For this example, I will use the AccountDetail quickform and put a new lookup control that is bound to a property called ‘PrimaryContactID’. The PrimaryContactID field stores the Accounts primary contact. The premise with this example to demonstrate defaulting a value into a lookup control, if a PrimaryContact does not exist for the Account then just default the lookup to the first contact associated with the Account. Simple enough example and good enough to demonstrate how to default the lookup (and entity.property).

What we need to do is add a Code Snippet Action Item on the Form Load. To add code on Form load, just click on your Form (we are using Account Details in this example) and then choose the ‘Load Actions’ from the form properties. Add a new action and choose ‘Code Snippet Action Item’.

The next step is to return the first Contact that is associated to the Account. We are keeping this simple by just returning the first one in the query, but you could also make your query more logical by returning based on createdate or some other criteria. Here is the code we will use on Form Load:

Sage.Entity.Interfaces.IAccount account =
(Sage.Entity.Interfaces.IAccount)form.CurrentEntity;
Sage.Platform.Repository.IRepository rep =
Sage.Platform.EntityFactory.GetRepository();
if (account.PrimaryContactID == null) {
Sage.Entity.Interfaces.IContact contact =
rep.FindFirstByProperty("Account",account);
account.PrimaryContactID = contact.Id.ToString();
}

Now lets explain this code abit. First, we get an instance of the account from the form’s CurrentEntity property. Next we need a repository to load up our contact. We are using the IRepository interface instead of RepositoryHelper because we are not going to use the ExpressionFactory or ProjectionFactory in this case. Next, we are just checking to see if the account has a primarycontactid or not. If not, we use the Repository to return the first occurance of a contact with the FindFirstByProperty method. Finally, we place the resulting contact’s ID into the account.PrimaryContactID property. This will also update your Lookup control on the form… there is no need to update the lookup controls LookupResultValue in addition to updating the entity.property.

When creating a lookup you can use the SeedValue and SeedProperty properties on your lookup to default the lookups result based on a Entity.Property from the current form’s entity.  To set this up is straight forward – putting the Entity.Property in the SeedProperty and putting a value in the SeedValue by mapping SeedValue in the Databindings.

Here is an example: The Account detail quickform has a lookup for Primary Contact. We want to only show those contacts for the current Account.  When you click on the Primary Contact lookup only those contacts for Abbott Ltd are displayed.

SeedProperty

This functionality is from using SeedValue and SeedProperty on the lookup.  The first thing to set is the SeedProperty to the Entity.Property that you want the lookup to filter on.  This is done in the properties for the lookup.

SeedValue

Next you will modify the SeedValue – we will use the DataBinding to map the SeedValue to the current Account ID.  We do not want to set the SeedValue in the properties list (as we did with SeedProperty) because we want the a dynamic value to be rendered from the current form’s entity property.  From the databinding select the datasource property on the left and map to the SeedValue Control Property on the right.  In this case, I mapped the SeedValue to MainEntity.Id by typing in MainEntity.Id in the Binding textbox. In this case MainEntity is the Account entity, so MainEntity.Id is referencing the Account.Id.

In the 7.2 release of SalesLogix Web you were introduced to the Application Architect and the Virtual File System. Immediately there was a flurry of information being created and consumed, some correct and some incorrect. In the training department at Sage we have even had trouble deciding what to call certain parts of the product. Our main concerns are to remain consistent with what the developers or product management decide to call the pieces and to train you on these subjects as best we can.

So now we talk about the VFS

In the past I have referred to the VFS as anything related to my customizations. There was a table in the database named VirtualFileSystem, there was the project workspaces that contained one or more VFSs, and there was the potential to be working with an “exported VFS”.

I was wrong in a couple places, important places mind you, and I was not alone.

Say it ain’t so

Sorry but it is so. Here is how I remember it:

Before the SalesLogix Boot Camp I was talking to a developer about a subject we were covering. In the Boot Camp we were going pretty deep into about 25 topics and I needed to have some real details about “the VFS” as I called it. As we were talking this developer stopped me and said: “You mean the model?” and I said: “uh yeah, the model in the VFS” and we moved on. I hadn’t realized that my affirmative statement was actually completely wrong. The same situation happened the next day and I finally asked for an explanation of the differences in semantics.

But it didn’t stick

So Boot Camp came and we started in on the particular exercise that included “the VFS”. There were several discussions about what the VFS was and was not and what else it was to be called. We brought in the idea of a model (which was in the book in the correct form) and that seemed to raise more questions.

After all we had gone 2 years as a group calling this thing the VFS. Something had to change. This is where the LFS idea came from. Someone from our PSG group suggested it be called the LFS for Local File System when it is exported. Sounded good at the time and we talked a bit about it and moved on.

What are we left with now?

What we are left with now is three distinct ideas:

• The VFS
• The Model
• Project Workspaces

VFS or Virtual File System

The VFS is a table in the database. It is called the VIRTUALFILESYSTEM table. It is used to hold the Model as well as some user settings for the dashboard on the web. This was covered well in the videos and book from Boot Camp – available at the developers subscription.

The VFS is also used to refer to the system of storing items in the table called VIRTUALFILESYSTEM, but much less often.

The Model

The model is your actual work. It is a set of mostly xml files containing mostly meta data used to describe the stuff you see in Application Architect. There are files for every entity, every business rule, every form, and just about everything else. Portals are in there along with their definitions too.

Realistically it is a folder on your hard drive or stored in the VirtualFileSystem table. To me it is like the changes in a visual studio project without the csproj or sln files. Visual Studio .net can use that folder perhaps, but without the csproj files it is really just a collection of files.

Project Workspaces

So when you pull your Model into Project Workspace Manager it becomes a Project Workspace:

This is why LFS is such a bad term. You can have more than one Model on your “Local File System” which one is the LFS? The model is in a location, either the VFS or on the local hard drive or on a network share somewhere. In either case it is hardly usable outside of a Project Workspace. You can use it and we do in many videos in the developers subscription, but really we spend most of our time in AA making modifications.

Wow that is confusing just break it down for me

OK, so your are confused. Just do this:
Stop referring to your Project Workspace as a VFS. If you want to know where to place source control or how to backup your changes you need to know the working path of the Model. Is it in the VFS or on the hard drive or a network share?

Can you export your VFS? No. You export your model from a Project Workspace by right clicking a project and then “Add”:

Can you backup your VFS? Yes. Just like any other table ;) You use SQL Server to do this.

Oh you mean backup your model? Sure. Just use 7-zip like any other folder ;)

I see. You mean backup your Project Workspace? Sure. Right click the Project Workspace and backup and restore as needed.

“Wait!” he says, “I want to import the entities and stuff I have in an “exported vfs” into the vfs that is in my database.” and he has learned nothing from this post.

You can import the changes from one project into another – remember a project is a model loaded into Project Workspace Manager – from the C:\ or network share OR from the VFS. So right click your destination project (the one in the vfs probably) and import from another project. Then you can choose the Project that you want to import from – the one on the C:\ drive or network share.

What is UTC?

UTC is Coordinated Universal Time. To us that is the same as GMT or Greenwich Mean Time. It is a way of referring to a time in a common way starting at a small town in England. Makes perfect sense right?

Why UTC?

So in SalesLogix the problem with timezones happens when you have one person from the east coast of the US updating data and another person on the west coast updating data at the “same time”. Lets say they both do it right now. It is early in the morning West Coast (not really but that is when this post is to be published). On the east coast the database will say something like 10am and on the west coast something like 7am. Then we both sync to the database (assuming your remotes change the clock on their laptop when traveling). The person on the west coast will probably have their overwritten because they happened “earlier” than the east coast person. This is true for the next 3 hours! Obviously we cannot have this and in version 6.2.? the upgrade process made everything in the database UTC (or universally the same time).

This means every time that is placed into the database needs to be in UTC time right? So we need to convert the time from our timezone to UTC before saving right? No. Not in the LAN. You guys know this. Do you know why?

Why not in the Lan?

The LAN sends everything through the provider right? That magical SalesLogix Provider. Referred to as SLXOLEDB.1 by developers and as an object on every server and workstation by administrators/implementers. When the change was made in 6.2.? (I was not around) the provider was written to take the time submitted by the user, the time on the machine it is on, and calculate UTC automatically for us. So we have not had to worry about it.

When remotes sync, they sync in UTC, when LAN users save data they save through the provider in UTC. Developers on the LAN have lived in an easy world.

How is it done in the Web?

Well in the web we still need to convert everything to UTC. Why? Because we said so.

Well in the lan you could just set a datetime field how you saw fit and it would be handled for you.
In the web you need to work with:

DateTime.UtcNow;

MSDN stuff here

it isn’t a big deal. If you want to save anything with a date or time you just have to ensure that you have converted the date and time to UTC. Using the above code takes the current time and converts it for you.

That is C# or asp.net code. What if you want to do the same in JavaScript or another language? Well you need to find the conversion for that language.
JavaScript version here

How can you tell?

The question remains “Does the web not go through the provider?” and then “Wait! I know it does!” Jason must be wrong.

Well I am wrong a lot, but not in this case I am afraid.

Here is the reason:
a connectionstring from the connectionstring.config on the web (actually Process Host in this case):

Provider=SLXOLEDB.1;Persist Security Info=True;Initial Catalog=SALESLOGIX_EVAL;Data Source=WINDOWS2003BASE;Extended Properties="PORT=1706;LOG=ONSVRCERT=12345;;ACTIVITYSECURITY=OFF;TIMEZONE=NONE"

and one from a UDL file I create for a lan customization or by using Application.ConnectionString:


SLXOLEDB.1;Persist Security Info=True;Password="";User ID=admin;Initial Catalog=SALESLOGIX_EVAL;Data Source=WINDOWS2003BASE;Extended Properties="PORT=1706;LOG=ON"


Notice that last part:


TIMEZONE=NONE


That tells the provider to NOT convert the dates and times to UTC. I am told this is a requirement. I changed my connection.config on a recent build and the site ran just fine, but I have yet to attempt a save of data or anything like that to see if there is an impact.

So Why go back to requiring UTC?

Well the database is still storing the information in UTC format only, so we are not going back to anything there. It is still the “new” way in the db. The reason on the web is that the web server is getting requests from many sources at once. You could have many users from many timezones sending in requests all at once. You cannot tell from the server side what timezone they are in. You can tell from the client and pass that information in, but that would kind of be the same problem wouldn’t it? Having to set a timezone before you could update any dates or times in the database? So remember the code that we are talking about runs at the server. The client (IE, FireFox or Chrome) has no automatic way to pass this information in to the server. Make sense?

While planning our SalesLogix deployment most administrators are worrying about where to put their sync server and how to open the ports for the website and soon they arrive at the “how do we let our developers do their work?” question. Some things to consider are:

• Do you have more than one developer?
• Do these developers have a machine that can handle a full SLX install sans sync/remotes?
• Do you have a staging server for the changes these developers will be making?
• How will you manage the integration of the changes made by these developers?
• Are you planning on using source control?

Most of the answers to the above questions should be yes. If you have more than one developer they should have a machine capable of running SalesLogix, SQL (Express), VS.NET 2008 and you should have a staging server or at least another deployment and setup on one of those machines for integration tests, a plan for managing those integrations and some sort of source control.

Let’s get started

First some nomenclature. At least one thing is commonly misrepresented by myself and many of the people I talk to. The VFS is a table inside the database. The Model is the changes you are going to be making – it is made of up of all of the xml files etc. Most of us call the model the vfs, but the model can be IN the vfs if you choose or exported.

To export or not export the model? I have asked several people in development and all agree – export the model from the vfs to the local file system. This makes compilation and deployment on the development machine faster and allows for source control to be applied. If you are a single developer working on a single project then perhaps you have a reason for leaving the model in the vfs, but probably not.

Now on the SalesLogix server you can have the model anywhere you like. Why? Because when you go to apply your changes to production you can either bundle the changes up from the staging server, copy the changes from project to project (exported project to project in the vfs in production) or backup the model on the staging server and restore it into the model in the vfs on the production server. You are not concerned in production about the time it takes you to build and deploy the few times you are required to do that in production.

Another great reason for leaving the model in the vfs in production is for backups. We are rather adept at backing up our whole database. This is something we have had to do a lot of in SalesLogix over the years so we have gotten accustomed to it. Doing this on the staging server and delivering the whole database to the client was another method. In either case you will export on the developers machines.

Apply Source Control

So now that you have your model exported from production you can get it on some network share and apply source control. We covered this in Boot Camp and it is also covered here. We used Git at Boot Camp and it is pretty awesome, but many of you already have a source control system in place. At this point you “apply” source control to that exported model. With Git this means creating a bare repo and pushing everything into it, with Subversion or others you have other options.

The only real trick is to use something that allows for optimistic locking. Take Visual Source Safe. The default source control for classic asp systems back before 2002 or so. It makes every file in the directory you control read-only. This causes problems with SalesLogix (and many other code systems) because we create new files, they are read-only and not checked out immediately, so then you get write errors. With something like Git you can create files and edit as you see fit and only at commit do you need to realize what you changed, apply a nice comment and then commit.

Just keep that in mind. Both Subversion and Git have their Tortoise UIs and we have videos in the developers subscription showing how to use Git and the PDF from boot camp is also available here.

Now bring in the developers

So the developers have SalesLogix installed on their machines with SQL Express and Visual Studio (if you want it – I suggest you will). They do a pull from the repo to somewhere on their local drive let’s call it “C:\vfslocal” and we will refer to it as “vfslocal”.

The developer then opens Application Architect and probably has only one model in their project workspaces – it is the one from the database they have connected to. This database should be a copy of the production database. It can have a model in it, we just don’t care about it as developers – that is for administrators later on.

Right click on the project workspaces and add a new workspace pointing to the vfslocal you created. Build it and press the run button at the top of Application Architect. You need to have a deployment configured as default and debug to do this, but that is covered well elsewhere. If you do not have IIS installed – that is ok. Application Architect comes with its own development webserver that will be used.

Developers make changes, they commit locally and they push good code up to the repo on the share location. All is well.

When the developers push their changes to the shared repo they are forced to reconcile their changes. This means they cannot go home until they have used a merge tool to ensure their changes are integrated into the code. They really want to do this – that is how they share their work. If this step fails or has a problem and something is overwritten then the source control system has a method for “rolling back” changes etc.

Let’s QA something!

Your staging server will be used here. The point of this step is to get the changes out of source control and into a production like environment. So we do a pull or get from source control of the entire model. If you were choosing to not use source control at this point you would be asking your developers to bundle everything up and send it to you. Either way you gather all the changes, apply them to some model somewhere. For us that is going to be a model in the vfs on the staging server. We want it to be as close to production as possible.

How do we do that? On the staging server (or connected to it) we open Application Architect and create a new workspace pointing to the model we just pulled from source control. It should show in our project workspaces now. Click on the model in the vfs and tell it to import from other project and choose the project you just created. AA will then suck all of the changes from the source controlled model into the vfs.

What have you done?

You have taken the changes that the developers have pushed to the repo and pulled them locally to the C: drive of the staging server and then imported them into the vfs. You can now build and deploy and check for quality as you see fit.

You still need to get them into production, but production can be on the machine next to you or at a client site. At this point you can backup the model in the vfs and restore it to a client production machine, copy the whole database if there were data changes too or create a bundle of all the changes and apply it to production. The options are limited.

What not to do?

Do not place source control on the output files (C:\inetpub\wwwroot\slxclient). This makes no sense. If you want a copy of these files then use a deployment snapshot instead. This was also covered in boot camp and in the various classes offered at Sage.

Do not have more than one developer working out of the database (vfs). This will cause a problem. The easiest one is both developers open AccountDetails, one makes changes and the other just looks at it unaware of each other. Both press save. The LAST ONE to save get his or her changes in the vfs the other one loses their changes forever. It is just that simple. Export your vfs and apply source control. Two ways to not have that happen to you.

Here is a basic diagram of the process as I see it. I have verified this information with several good resources, but comments are welcome and edits may be made :)

Service Pack 2 for Sage SalesLogix v7.5 introduces Sales Orders as its own Main view in the Web Client. This is a new feature.

What is a sales order?

A sales order tracks the products purchased by your accounts. Sales orders include information such as the date the sale order was made, the products ordered, the sales order status, and so on. A sales order is independent of an opportunity—in v7.5.2, a sales order is required to be associated to an account instead of an opportunity.

How do I create a sales order?

Create a sales order on the Web in a number of ways:

• From the Menu Bar, click New > Sales Order.
• From the Sales Nav Bar, right-click Sales Order, and then click New Sales Order.
• From the Opportunity Detail view, click the Sales Order tab, and then click the Add button.
• From the Opportunity Detail view, click Add Sales Order from the Common Tasks pane.
• From the Sales Order Detail view, click Copy from the Toolbar.

If you create a sales order from an opportunity, the products included in the opportunity are automatically added to the sales order for you. Otherwise, you need to add the products and quantities manually.

Is multi-currency available?

Yes! If your administrator configures multi-currency, you can view the sales order snapshot in three currencies: 1) Base, 2) Sales Order, and 3) My Currency. Currency defaults use the same settings as opportunities. If your administrator also allows access, you can also change a sales order’s rate at any time before closing the order.

I created a sales order. Now what?

If your company uses an integration product such as Sage SalesLogix ERP Link, sales orders provide a way to automatically pass order information to your accounting system for processing. If installed, ERP Link adds several new Network Client buttons and tabs to help you manage sites (warehouses) and post orders. ERP Link currently supports integration with the Network Client only; however, any orders created in the Web Client also appear in the Network Client’s “Order Details” tab, and SalesLogix/ERP Link can then process them from there. In other words, if you want to use ERP Link to automate front-end processing on the Web with your back-end accounting system, your company must use both the Network and Web installations.

If you do not use ERP Link, you can still use sales orders in the Web and Network Clients as a manual approval and tracking system. From the Sales Order Detail view, copy the Sales Order Snapshot information into an e-mail, and send it to your shipping or accounting teams.

******************************************UPDATE********************************************

Currently, ERP Link does not support SalesLogix v7.5.2. When support is available, it will manage the flow of Sales Orders back and forth between whatever ERP system with which it is connected, for example MAS 500, AccPac, and others. Consult the product release notes for the latest details.

Why another Process Orchestration Post?

If you do not realize it already most of the work we do in the training department is in preparation for our SalesLogix Developer Training Courses or in response to your posts in the Developers Subscription.

We also take a close look at what is changing in upcoming releases. Process Orchestration changes are part of SalesLogix Service Pack 2 and they really boil down to Preconditions.

Preconditions to what?

These are conditions that are run before the process is picked up. When the process host is started it will “keep track” of these preconditions and only run the selected assembly if the preconditions are met. So they are preconditions to anything being executed.

Alternatively you may have placed these conditions into your process. Something like an IF in your process checking to see if the state was changed then only do something if it was changed to ‘AZ’ or something along those lines. I thought that I might want to see if the state was changed FROM one value TO another value, but that does not seem to be the use-case
for these Process Orchestration Preconditions.

So we understand PO, how do we use the Preconditions?

Keep in mind I am using the BETA of SalesLogix 7.5.2, so some of this may change.

You basically update the processstart.xml. In a previous post I talked about the processstart and processlib xml files. Process lib is used to list and register the available processes that can be run. Process start tells the host what to run when something changes. Now we can augment that with some preconditions:

<processStartConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<event name="PropertyChanged">
<entityType id="63b61866-48ec-422b-b2bb-09a199b26cd8" name="Sage.Entity.Interfaces.IAccount, Sage.Entity.Interfaces" memberFilter="Division" condition="Division='HQ'">
<runProcess name="DivisionSendMail" />
</entityType>
</event>
</processStartConfiguration>


This is right out of the documentation! A few changes are:
entityType id="63b61866-48ec-422b-b2bb-09a199b26cd8"
I am told by the developer that this is “future code” – pretty neat huh? Code from the future. The developer’s name was not Marty. The idea behind this id is so the xml file can be easily parsed for the specific entries. More to come on that I guess. Also since this file “may change” in the future and is written to dynamically at runtime, you lose all of the comments at the top – these were moved to a processstart.readme.txt (or so I am told).

Now for the good stuff:
condition="Division='HQ'">

This is the precondition. This is saying on the Account that is changing, only run the process if the Division now equals ‘HQ’.

Right out of the docs, we have some other options and examples:
condition = " Division='HQ'"
condition = "Closed = true and SalesPotential > 1000000"
condition = "Employees=45"
condition = ""

The queries shown do not go to far into what is possible, but from the docs we can see that they conform to the Expression Language Features – more to come on that one.

Where does that leave PO?

Well you have a few more options. You can have another way to control when your process will and will not run. Even in these simple examples you can see that updating these conditions without this change would have required changing code and a recompile. Not any longer!