Archive for v11

UPDATED: CorasWorks Application Service capabilities index

It’s been a year since the CorasWorks Application Service was first released publicly – and if you missed it before, we previously posted a concise listing of everything you could do with the version of CAPS that launched with v11.3.0.

Now that CorasWorks v11.3.2 has been released, it seems like the right time to update the capabilities index for CAPS as much has been added in the last two platform releases. Just see for yourself…

Added in v11.3.1

  • Addition of a new “ProcessGlobalVariables” method providing create, edit & delete capabilities for your CorasWorks Global Variables
  • Addition of a new “ProcessList” method providing create, edit & delete capabilities for SharePoint Lists & Libraries
  • Addition of a new “StartWorkflow” method allowing you to kickoff SharePoint workflows via CAPS call
    • Addition of a new “RunOptions” parameter to the StartWorkflow method to allow for setting the corresponding run parameters (Added in v11.3.2)
  • Addition of a new “ListType=External” parameter to the ProcessBatchData operation to provide create, edit & delete capabilities against External Lists leveraging External Content Types
  • Addition of a new global “DatesInUtc” parameter, available on all CAPS operations, for telling the Service to interpret & use the UTC value of any & all CorasWorks date variables within your call
  • Addition of a new global “ContentDisposition” parameter, available on all CAPS operations, for specifying the Content-Disposition header you want the Service to specify for its response
  • Addition of a new “Title” parameter to the CopyFile method, which enables the renaming of a CorasWorks Action or Central View definition if that is what’s being copied
  • Improved error handling for mal-formed XSLT paths

Added in v11.3.2

  • Addition of a new “GetContentTypes” method for enumerating all the available Content Types
  • Addition of a collection of new parameters on the “GiteSiteCollections” method…
    • GetSubsites = true/false, if true returns the children of the site the CAPS call runs in the context of
    • SiteLevels = Integer, specifies the number of levels deep to iterate through & return children sites
    • StartAtRoot = true/false, if true tells CAPS to start enumerating subsites from the root of the Site Collection
  • Addition of a pair of new parameters on the “GetSiteUsers” method…
    • GetUserProfiles = true/false, if true returns the data from the User Profile Service instead of the User Information List of the current site collection (Requires use of Server CAL and User Profile Service)
    • Properties, a comma-separated list of the properties on the object that you wish to return (if absent/null, all properties are returned)
  • Addition of a new “Properties” parameter to the GetSiteInfo and GetListInfo methods, a comma-separated list of the properties on the object that you wish to return (if absent/null, all properties are returned)

CAPS is like a fine wine – it just keeps getting better with age!

Quick Tip – Attribute Value Templates in XSLT

Previously, I blogged about a quick & easy shorthand method for referencing an XSL variable within an attribute value – this capability is really a subset of a capability called “Attribute Value Templates” in XSL (reference).

What’s great about what I’ll call AVTs for short is that you’re not limited to just referencing existing XSL variables; once an AVT is instantiated – by use of the wrapping {} curly brackets – that attribute can then be any valid XSL expression.

Take for example a common use case of dynamically generating some HTML using XSL and, in doing so, wanting to create HTML attributes using data points from your source XML. In the past, you may have done something like this:

<div>
   <xsl:attribute name="id">
      <xsl:value-of select="concat('Task',TaskID)"/>
   </xsl:attribute>
   <xsl:value-of select="Title"/>
</div>

But using an AVT, this same line could be re-written as:

<div id="{concat('Task',TaskID)}">
   <xsl:value-of select="Title"/>
</div>

This is just a simple example but, in general, if you can create an expression as part of a “value-of select”, you can do it within an AVT. Support for full expressions within an AVT thus helps ensure you can write stylesheets that are now both smaller and easier to read.

Hiding a Java Applet until it’s fully loaded & ready to display

I recently designed & implemented an application for visualizing multiple data sets with interconnected many-to-many relationships – some real complex radial visualization type stuff. To satisfy the requirements, a Java applet was leveraged for the interactive UX. One nagging issue I had though was that, by default, when you load a Java applet on a web page, you only see the default Java loading animation (a coffee cup inside a blue spinner) while the JAR file is being downloaded & launched.

In my implementation though, I was leveraging the newer JNLP-based approach of defining the applet’s parameters; and not only is my JNLP dynamically generated server-side (based on end user inputs & interactions), contained within my JNLP are some attributes for loading data via CAPS (the CorasWorks API) calls. The issue is that the JNLP loading & CAPS calls all happen after the JAR has been loaded – leaving my users to stare at a blank screen for sometimes 5 seconds or more.

Enter the concept of Java status and event handlers (reference). Starting with the release of Java 7 (July, 2011), web developers can tap into key statuses and events of an applet on a page; and just like we often do elsewhere in our client-side development, we can then use those event handlers to improve the user experience. In my case, that meant:

  1. Keeping the Java applet invisible while it loaded everything
  2. Displaying my own loading image/animation while it loaded
  3. Hiding the loading content and making the applet visible once ready

And here’s how I did it…

First, I ensured that I had the “java_status_events” property on my parameters object set to true. Then I made sure I had an ID property & value for the applet specified in my attributes object. Something like this:

<div id="AppletContainer" style="visibility:hidden">
    <script src="//www.java.com/js/deployJava.js"></script>
    <script type="text/javascript">
        var attributes = {ID:'MyApplet',width:1000, height:700};
        var parameters = {
            jnlp_href: 'URL-to-JNLP-Service',
            java_status_events:true};
        deployJava.runApplet(attributes, parameters, '1.6');
    </script>
</div>

Then I created a DIV, which I placed directly above my “AppletContainer” DIV:

<div id="LoadingContainer">
    <img src="images/Loader.gif">
</div>

Finally, I added an event handler to hide my “LoadingContainer” and display my “AppletContainer” when the applet is done loading:

$(function() {
    KTMApplet.onLoad(function() {
        $('#LoadingContainer').hide();
        $('#AppletContainer').css('visibility', 'visible');
    });
});

There you go – a solution for showing my own custom loading animation while my Java applet loads, then displaying the applet as soon as its ready. There’s other events & statuses you can attach to, but chances are, this is the one you’ll use most often.

And in case you’re wondering, you do have to use the CSS ‘visibility’ property, as opposed to display (i.e. show/hide with jQuery) because an applet that is hidden – say in a DIV with a “display:hidden” style – will not register its event handlers, thus preventing your ability to display it when loaded.

SharePoint Conference 2014 aftermath – Customizing Forms

As a blog primarily focused on the technical aspects of building applications in SharePoint, I won’t drone on about the far-reaching impacts of “The End of the InfoPath Era” – this was already announced in the weeks leading up this year’s SharePoint Conference, and then (sort of, but more on that later) given more clarity during the Conference itself. In short, although end-of-life support for InfoPath will extend until 2023, last year’s release will remain the final one to include any new features or functionality, while fixes & patches will be at the pace you’d expect from a Microsoft product on its way to sunset.

Sitting in the room at SPC14 with hundreds of my fellow SharePoint developers, users & executives, I got a first-hand glimpse of what Microsoft sees as its path, or really paths, forward. We knew Microsoft meant business when the session was given a primo time slot & 3 Microsoft employees to present; in the end, what we got was a scatter shot of four possible options for replacing custom InfoPath forms:

  1. Using Excel Surveys, an apparently little known feature for creating custom forms directly inside an Excel document & that write to a worksheet therein.
  2. Using a new, yet to be released “Forms Over SharePoint Lists” web-based designer for creating custom forms in SharePoint 2013 (and yes, that acronym is FOSL, pronounced ‘fossil’ by the MS reps themselves – insert irony joke here).
  3. Possibly using Word for structured document forms – this I say “possibly” because MS committed only to providing a roadmap for this option by the end of 2014; no actual product yet.
  4. Using Access Apps, which if you used them in SP2010, seem reminiscent of the Office Business Apps (OBAs) that were touted then.

With such a wide range of choices, and comparatively little guidance on when to use which & where, I couldn’t help but think the flexibility & power of the CorasWorks Actions Framework provides a much-needed alternative. In the coming months, I suspect more vendors will try to fill the “custom forms” gap with new products – but we’ve been building apps with & improving our Actions Framework, including our web-based designer (the Actions Wizard) for more than 8 years now; this is a feature set CorasWorks knows well!

And as an architect that’s designed & implemented 100+ custom applications on SharePoint, I also know just creating a custom form a solution does not make; what if you want to apply a custom form to more than one list, across multiple sites, site collections or web apps, with a single centralized definition – none of the MS approaches facilitate this, while the CorasWorks platform has for years. Or how about custom forms that are exposed depending on the current values or stage an item is in, can trigger Workflows anywhere in the SharePoint farm, or are security trimmed based on the currently logged in user? All core features of the CorasWorks Actions.

Plus, in the coming months, while others are just starting to explore the world of InfoPath alternatives, CorasWorks will be expanding our Action framework further to include integration with other data sources & providing greater flexibility & customizability in the form UI.

So while the InfoPath announcement and SPC14 have put the topic of custom forms for SharePoint at the forefront, CorasWorks has been building & improving our platform – which includes this key feature – since the SharePoint 2003 days.

Enable Logging in CorasWorks v11

The CorasWorks v11 platform adds a wide range of capabilities into the application builders toolbox – and as every good builder & developer knows, sometimes the best way to track down any issues that may arise is by getting the server to log the details of what it’s doing behind the scenes.

Just like native SharePoint has a wide range of logging & debugging options, so does CorasWorks v11. Beyond all the built-in client side tools (putting web parts in debug mode, Wizards that guide you through proper configuration, intelligent CAPS error responses, etc), you can also enable server-side logging. Doing so will enable key pieces within the CorasWorks framework to write logging events into a special CorasWorks Application log that’s then accessible via Event Viewer on the web server.

NOTE: Because the event logging provided is rather verbose, we do not recommend leaving event logging enabled permanently, and use of it within Production environments may impact performance, so plan accordingly.

Here’s how it’s done…

  1. Browse to this location on each (and every) WFE in your farm: “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\XX\Resources” where ‘XX‘ represents the hive for the version of SharePoint you’re running (12=SP2007, 14=SP2010 & 15=SP2013)
  2. Within that folder, locate the following two RESX files: “CorasWorks.Workplace.Data.Engine.Resources.resx” & “CorasWorks.Workplace.Data.Engine.Resources.en-US.resx”
  3. Search the files for the following tag; in most cases, it should be near the end of the page: <data name=”LogEvents” xml:space=”preserve”>
  4. Set the <value> node to True:
    LogSetting
  5. Repeat steps 3 & 4 for both RESX files on all your WFEs, performing an IIS Reset on each box after you’ve updated both files
  6. Finally, repeat the test or behavior you were hoping to troubleshoot, then open the Event Viewer on the WFE and browse the CorasWorks Application log for details on what’s happening behind the scenes

Again, once you’ve resolved your issue, you want to be sure you set the “LogEvents” property back to False – but now you know yet another way CorasWorks makes it quicker & easier to build (and because no one is perfect, also troubleshoot) your applications in SharePoint.

CorasWorks support for In, Includes and NotIncludes filters in SharePoint

Starting with SharePoint 2010, three new CAML filter operators were added, but scant details and examples mean that even 3+ years later, few people know about or use them. Fortunately, the CorasWorks platform (including CAPS) fully support these new operators – and here’s some insight on how you can take advantage of them!

The <In> operator

This is probably my favorite addition of the three and the one I use most often; what it does is allow you to collapse what would normally be a string of multiple <Or> filters into one single <In> condition.

For example, you want to filter a native Tasks list to show all items that are “Not Started”, “In Progress” or “Waiting on Someone Else”; you would likely string three together three <Eq> conditions inside <Or> operators (or even string two <Neq> filters for the other possible values of “Completed” & “Deferred”).  Something like this:

<Where>
<Or>
<Or>
<Eq>
<FieldRef Name=”Status”/>
<Value Type=”Choice”>Not Started</Value>
</Eq>
<Eq>
<FieldRef Name=”Status”/>
<Value Type=”Choice”>In Progress</Value>
</Eq>
</Or>
<Eq>
<FieldRef Name=”Status”/>
<Value Type=”Choice”>Waiting on Someone Else</Value>
</Eq>
</Or>
</Where>

Now let’s see that same filter written using the <In> operator:

<Where>
<In>
<FieldRef Name=”Status”/>
<Values>
<Value Type=”Choice”>Not Started</Value>
<Value Type=”Choice”>In Progress</Value>
<Value Type=”Choice”>Waiting on Someone Else</Value>
</Values>
</In>
</Where>

How’s that for efficiency? Easier to read and easier to write – bet you never thought you’d say that about a CAML query.

The <Includes> operator

If the <In> operator is akin to a string of <Or> conditions on a single value, the <Includes> operator is a specialized option for working with multi-select Lookup values; think of it as a “contains”, but intelligent enough to differentiate if you have similar text in multiple Lookup values.

Sticking with our Task list example, imagine wanting to filter by the multi-select Lookup that is the Predecessors column to find all Tasks that have a specific predecssor – this would allow you to see all the Tasks that might be impacted by a specific one slipping. You can’t use an <Eq> condition because that would only bring back items whose only predecessor is the Task you want – again, the <Includes> gives you the advantage of working more like an intelligent contains, like such:

<Where>
<Includes>
<FieldRef Name=’Predecessors’/>
<Value Type=’Lookup’>Task 4</Value>
</Includes>
</Where>

The <NotIncludes> operator

This one is now simple because it’s just the inverse of <Includes>. Still specifically built for multi-select Lookups, it would allow you to filter for, in our same scenario, all Tasks that do not have a given Task as a predecessor – it’s the intelligent version of a “does not contain” filter, implemented as:

<Where>
<NotIncludes>
<FieldRef Name=’Predecessors’/>
<Value Type=’Lookup’>Task 4</Value>
</NotIncludes>
</Where>

References

Not that there’s much more detail there, but here are the corresponding MSDN links for these operators as well:

Securing & Hardening SharePoint Sites for External Users

For most organizations, it’s not a question of “If” but “When” – when will you want, or need, to collaborate with an external user on an application hosted in within your SharePoint farm? Over the years, CorasWorks has helped customers across numerous verticals, with a myriad of use cases and requirements, improve the efficiency of their solutions by giving external stakeholders direct access to the data they should see. More importantly, our platform and best practices have enabled customers to architect and implement their own secure solutions as well. Let’s look at the key concepts that allow this.

Basic Security

As a favorite childhood cartoon of mine reminded me every Saturday morning, knowing is half the battle. Liam Cleary, a SharePoint MVP, did a great write up in 2012 on educating site owners and SharePoint administrators on just what might be out there and visible to the world with the default settings. I suggest a quick read; after all, the first step in good security is knowing what you’re protecting.

Setting up Your Collaboration Spot

Whether it’s an Intranet-Extranet scenario, a customer/vendor portal, a system for publishing approved content from a private site to a public one or anything else in which you want to decouple source data from the end user, there’s a few basic concepts that the CorasWorks v11 platform will help you leverage to separate & secure your solution.

  1. First, because all the CorasWorks components support full CRUD (Create, Read, Update, Delete) operations across Site Collections and Web Applications, you can securely segment your external partners & users from your internal ones.
  2. The CorasWorks platform also contains numerous features for copying and/or moving content from one place to another; again, across Lists & Libraries, across Sites, across Site Collections and across Web Apps.

    Leveraging our Actions and/or CAPS, you can enable process owners and approvers to push content from a secured, internal site to an open or partner-secured external site. You can also automate the process using Timers (i.e. every Monday at 5AM, check for and publish the newest approved content) or Triggers (i.e. upon Status=Approved for Release, publish to external site).

  3. And perhaps the most powerful option: if you do not want to copy or move data between sites but instead want to give your external users direct access to only the data they should see – say a customer portal that you want to display real-time inventory data – then CorasWorks is the tool to use.Our platform enables the creation of a secure “proxy” within the SharePoint farm that can process requests between say a Customer Portal site and a secured internal site.

    This design allows you to leverage a service account to provide full CRUD operations against any SharePoint data in the farm, but invisible to the end user – so they cannot see anything but the data you choose to expose to them (i.e. think column-level security). The end user is unable to even see where the data comes from, and their account doesn’t have access to it even if they did.

Couple this with some easy changes to secure away some of the “revealing” pages that Liam describes, like the All Site Content page (we’ll cover this in a future blog), and you’ve got a robust yet secure option for collaborating with all your stakeholders, internal or external.

The CorasWorks Platform – When to use What

So you have the CorasWorks Platform and are diving into creating awesome solutions for all of your users, hopefully even show off how great you are and how wonderful SharePoint can be.  Maybe you are a power user and you are ready to take on a larger challenge and dive into the world of XML and XSLT.  Or, perhaps, you are already an advanced builder, but you are looking to deliver some quick wins to your users.   Well, I’ve been in your shoes and this blog will help guide you along your way as you come to master our tools.

Basic Components

Our Basic Components are very powerful and, for the most part, you can put one on a page, point it to an existing SharePoint List or Library anywhere in your farm and be up and running in minutes.   If you have similar data on multiple sites – again, anywhere in your farm – you can even quickly aggregate them all together into one nice centrally located view.   Once you start adding Actions through the CorasWorks Action Wizard, you are really on your way to building most any type of basic application.

While the Basic Components are very powerful, especially when combined with our Action framework, they come at a cost.  As a general rule the easier something is to use, the less flexibility it will have.  At some point most of us will find ourselves needing to build a solution where the basic components just won’t meet the requirements.

CAPS (and previously the Advanced Components)

Our new CorasWorks Application Service, known as CAPS, provides you with an incredible amount of power and flexibility when it comes to building more complex solutions and having control over the user interface and experience.   With CAPS you can quickly and easily work with any data from across your SharePoint environment.  Our legacy Advanced Components also provided a more extensible framework; the External Data Provider let you easily connect to a variety of external data sources, while the Mashup Adapter let you combine data from a variety of sources into one ready to consume output.

The data retrieved and aggregated through all of the above manners can be transformed using XSLT.  With the legacy Advanced Components, you were limited to XSLT 1.0, but with CAPS you have the full power of XSLT 2.0 at your disposal, making CorasWorks the only application development platform on SharePoint with an XSLT 2.0 processor.  Using XSLT or even client-side scripting consuming JSON (which CAPS also supports), creating a rich UI is easier than ever.  Even the legacy Custom Display Adapter or Chart Display Adapter have vast degrees of flexibility, your only limitation often being imagination and skill.

A Place for Everything

The beautiful part about the CorasWorks platform is that you’re never completely locked into one path or the other; you can mix Basic Components, CAPS, legacy Advanced Components and even other 3rd party and custom controls.   Need to build a solution with a complex multi-level nesting of hierarchal data? Make the most of CAPS and client-side technology to create a UI that loads child data on demand.  Need your users be able to quickly update data and manage lookup values?   Give them some Basic Grids and Actions.   Want to empower those same users to setup different views of data retrieved from multiple SharePoint and non-SharePoint sources?  Connect the output from CAPS (or a legacy Advanced Provider) to a Basic Grid by selecting the “Advanced View (XML Based)” option as your view type so your users can make use of Basic Grid functions they are already familiar with including grouping, sorting and conditional formatting.

Wrapping Up

There is never just one way to design and build a solution, and ultimately those decisions will be driven by factors such as time and cost as well as other considerations such as your user base.  With the entirety of the CorasWorks Platform, you have the ability to approach a solution from a variety of ways.   As a general rule though, think of the Basic Components as a way to quickly connect to SharePoint Lists and Libraries, empowering your users to work with that data through our Actions.   CAPS, and the legacy Advanced Components before it, come into play when the underlying data becomes more complicated through joining multiple sets of data together, applying complex transformations through XSLT, and/or working with external data sources.  You will also want to leverage client-side technologies with CAPS when you want to have more control over the user interface and experience.

I hope this article has been helpful as a high level review of when and how to leverage everything CorasWorks has to offer. Keep building!

CorasWorks v11.3 and SharePoint 2010 Service Pack 2

Lately, the CorasWorks Support team has been receiving questions concerning SharePoint 2010’s Service Pack 2.  The Service Pack was released late in July 2013, and users would like to know if the CorasWorks Solutions and v11.3 Platform are compatible with it.

CorasWorks has been testing the SharePoint 2010 Service Pack 2 with v11.3.  Our testing hasn’t found any problems requiring changes to the solutions or the Platform components.  We have had similar responses from users who have already installed the Service Pack 2.  Feel free to install SharePoint 2010 Service Pack 2 into your CorasWorks-based SharePoint 2010 environments.

Naturally, the SharePoint 2010 environment is multifaceted, one with many possibilities of server, network, security, and other options.  Should you see any unexpected behavior after installing Service Pack 2, report the behavior to the CorasWorks Support team.

Thanks!

CorasWorks Support
Support@CorasWorks.net

Split, Join & Distinct – Working with Strings in XSLT 2.0

Here at CorasWorks, the ability to leverage XSLT 2.0 within our SharePoint-based applications – thanks to the CorasWorks Application Service – has added a lot in the way of efficiency. We’ve previously blogged about the myriad of Date Formatting options (here), and using RegEx to parse content from the ugly HTML markup SharePoint creates for multi-line text fields (here). Another area though that has improved vastly with XSLT 2.0 is string functions; specifically, let’s look at the tokenize(), string-join() and distinct-values() functions.

As is often the case, it’s not that these sort of routines weren’t possible in XSLT 1.0; they were just inefficient, took more lines of script to write and were possibly even prohibitively complex to come up with on your own. The new functions in XSLT 2.0, by contrast, are optimized, compact and intuitive to write.

Take splitting a string based on some delimiter, a fairly common use case; using the tokenize() function within a for-each statement makes this trivial. For example, SharePoint frequently stores certain data as a string delimited by the characters “;#” – item attachments and multi-select Choice, Person & Lookup values are just some of the data points SharePoint stores in this format. With XSLT 2.0, these values could be parsed out simply as such:

<xsl:for-each select=“tokenize(MyColumn,’;#’)”>

<Item><xsl:value-of select=“.”/></Item>

</xsl:for-each>

The inverse is also equally straightforward; assume you have an XML node set you’d like to concatenate the values for using some delimiter of your choosing. This example would take the Assigned To values for all Tasks and join them into a single element called “StringJoin” with each value separated by a semicolon and a space using the string-join() function:

<StringJoin>

<xsl:value-of select=”string-join(Tasks/AssignedTo/text(),’; ‘)”/>

</StringJoin>

Following that example though, if more than one Task is assigned to the same person, you’d get duplicate names in the “StringJoin” value; so let’s see how a node set could be created with just the distinct names via the distinct-values() function:

<xsl:for-each select=“distinct-values(Tasks/AssignedTo)”>

<DistinctName><xsl:value-of select=“.”/></DistinctName>

</xsl:for-each>

These three functions go a long way to optimizing and simplifying the XSLT you may write, and we’re lucky to be the only application platform on SharePoint that supports them and all the other advantages XSLT 2.0 affords!