Guide
Developer's Guide
Configuration Settings
Developer's Guide : Configuration : Configuration Settings Overview
Overview
Configuration settings are very important for integrating with MemberSuite’s API. They allow you to test for things that are part of an association’s particular configuration.
As a developer, you’ll want to avoid hard coding items in your software that could change. Additionally, you might want to reference configured items in the association’s system. This presents a couple of unique challenges.
- The first challenge is configuration. If you store your configuration in a local file, the only way you can change it is to open the file directly on your server. This is obviously not ideal.
- The second challenge is if your code relies on a custom field being present to add a value into that field and someone deletes that field, your code would break immediately.
Using configuration settings solves both of these problems.
Link configuration setting to field or object
A configuration setting can be a simple name/value pairing or it can be linked to a configuration object in MemberSuite.
If you link a configuration setting to a field or other object in MemberSuite, the setting cannot be deleted. This means you can be sure that the dependencies of your application will remain intact, impervious to accidental deletion by an unsuspecting client.
Another advantage to using a configuration setting is that you can create abstracts for parts of your code.
Example
You have code in the portal that checks to see if a member is associated with a particular membership type, such as Alumni. The code looks like this:
if ( member[“Type”] == “594811f7-0006-4feb-b7c1-ae841b42a9c2”)
{ Response.Write(“Your membership is invalid.”);
This is brittle code because if the code is changed it can pose two problems:
- The code will break if the membership type (that corresponds to the ID) is deleted from the configuration. However, using a configuration setting would keep people from deleting a configuration relied on by external code.
- If you make a sandbox of the association and you want to test new website code in the sandbox, the Membership Type ID in the code belongs in the original association, not in the sandbox. You would have to change it to the sandbox ID, test it, and change it back when you go live.
Instead, you could create a configuration setting named CFG_MEM_ALUMNI, and write the following code:
var alumniTypeID = proxy.GetConfigurationSetting( “YourDomain”,”CFG_MEM_ALUMNI”).ResultValue;
if ( member[“Type”] == alumniTypeID) { Response.Write(“Your membership is invalid”);
Using this code means that:
- MemberSuite automatically prevents someone from deleting the code. If someone tries to delete the code, a message appears letting him or her know that some part of the MemberSuite code relies on the setting and it cannot be deleted.
- When you make a sandbox for an association, MemberSuite also moves the configuration settings for the association to the sandbox. Your code will point to the correct ID, no matter what environment the application is in—sandbox or production. This is not possible with a hard-coded ID.
API
Developer’s Guide : API : API Overview
Overview
The MemberSuite System was designed with a Service Oriented Architecture. Simply speaking, this means that while object-oriented principles dominate the internals of the system, all significant functionality provided by the System is exposed via a series of endpoints, or services. The services comprise our Application Programming Interface, or API, and allow external applications access to System functionality. The baseline MemberSuite user interface and surrounding services makes use of exactly these services to do their work. The result of this architectural design is a clean separation of concerns between the User Interface, running agents and jobs, and the core of MemberSuite itself. The other benefit is the ability of external developers to extend, integrate with, and leverage the MemberSuite platform for their customers.
Developer’s Guide : API : Configuration Settings
As a developer, you’ll want to avoid hard coding items in your software that could change. Additionally, you’ll want to reference items in the association’s system that are configured. This presents a couple of unique challenges.
The first is configuration; if you store your configuration in a local file, the only want it can be changed would be to access this file directly on your server. This is obviously not ideal.
The second is worse; let’s say your code relies on a custom field being present to add a value into that field. What happens if someone delete’s that field? Your code would break immediately.
To solve both of these problems, we have the concept of Configuration Settings. A Configuration Setting can be a simple name/value setting, or it can be linked to a configuration object in MemberSuite. If you create a linked configuration setting – to, say, a custom field – no one will be able to delete the object out of the system. This means you can be sure that the dependencies of your application will remain intact, impervious to accidental deletion by an unsuspecting client.
We strongly suggest that you use Configuration settings. The other huge advantage is that you can abstract away certain parts of your code. Say you have code that checks to see if a member is of a particular membership type, say Alumni. How do you do that? Let’s say you write code like this:
<code><span class="hljs-keyword">if</span> ( member[<span class="hljs-string">"Type"</span>] == <span class="hljs-string">"594811f7-0006-4feb-b7c1-ae841b42a9c2"</span>)
{
</code> <code>Response.Write(<span class="hljs-string">"Your membership is invalid"</span>);
}</code>
OK. But this is brittle; what happens if the ID changes? If you have to point your code at another association? Instead of doing this, you could create a configuration setting named CFG_MEM_ALUMNI, and do this:
var alumniTypeID = proxy.GetConfigurationSetting(“YourNamespace”,“CFG_MEM_ALUMNI”).ResultValue;
if ( member[“Type”] == alumniTypeID) { Response.Write(“Your membership is invalid”); }
Developer’s Guide : API : How To: Create Configuration Settings
To Create Configuration Settings:
- Go to Setup
- Scroll down to Advanced Settings
- Go to Configuration Settings
Developer’s Guide : API : Search in MemberSuite
Overview
The most common thing you will do in MemberSuite is to pull data out of the system. The mechanism for querying data in MemberSuite is called Search. There are two primary methods for search:
- MemberSuite Query Language (MSQL) – this is a SQL-like language that allows you to select, insert, and update records
- Search object – this is a object that represents a search, including search criteria, output columns, and sorting
MemberSuite provides an easy service for converting a MSQL string to a Search object, because internally, MemberSuite uses Search objects for everything.
MemberSuite Query Language (MSQL)
The MemberSuite Query Language is a SQL-like language that let’s you SELECT/INSERT/UPDATE records. The basic syntax:
<code><span class="hljs-keyword">SELECT</span> <<span class="hljs-keyword">columns</span>> <span class="hljs-keyword">from</span> <searchType> <span class="hljs-keyword">where</span> <criteria>
<span class="hljs-keyword">UPDATE</span> <record> <span class="hljs-keyword">SET</span> <fieldsToSet> <span class="hljs-keyword">WHERE</span> <span class="hljs-keyword">ID</span>=<<span class="hljs-keyword">id</span>>
<span class="hljs-keyword">INSERT</span> <span class="hljs-keyword">INTO</span> <record> (<<span class="hljs-keyword">columns</span>>) <span class="hljs-keyword">VALUES</span> (<valuesToInsert>)
</code>
You can execute MSQL via the ExecuteMSQL method in the API. Some examples of MSQL queries: