jeremysublett.blogspot.com Open in urlscan Pro
2a00:1450:4001:828::2001  Public Scan

Form analysis
0 forms found in the DOM

Text Content

JEREMY SUBLETT

SharePoint, Azure, .NET and everything in between.





TUESDAY, MAY 13, 2014


CREATING A DOCUMENT SET WITH SHAREPOINT DESIGNER 2013 WORKFLOW



Synopsis: This post describes the challenges with creating a document set via a
SharePoint 2013 workflow.

My client needed the ability to fill out a form, then trigger a workflow for
various approvals. As approvers went through various process, then needed a
place to collect documents. A document set made sense here and it only made
sense that the workflow create the document set.

So I set off researching how to do this. I found a good article by Ann Stenberg
on technet which walked through this process for 2010. It exactly what I needed.
In the workflow section, you can see that it simply creates a new document set
by creating a new list item. And that made sense because it was really a folder,
sort of, which was itself an item.

Now that I understood this, I first created a new document set following the
instructions here manually. I manually created a document set from the new item
menu and that worked fine. It provides a nice landing page for the document set
too. Fine.



(By the way, as you see above I used my own content type which simply inherited
from Document Set called Sample Document Set)

Next, I went on to create a site workflow (based on SharePoint 2013) in
SharePoint Designer to prove this out. I added a create item action and
specified the following:

Content Type ID: Document Set Path and Name (*): 234 *

* This was just some arbitrary value that was to represent my form ID
eventually. It would become my document set name/folder.

I manually ran the workflow in the browser. It worked, but I didn’t get what I
wanted. I got a plain old folder instead. Not what was supposed to happen.
Thanks SharePoint. And there was no friendly welcome page that the other
manually-created document sets have.



After looking at this with SharePoint Manager it was the right content type, but
it was just a folder to the user. Everything was exactly as the other items.



By the way, SP Manager 2013 Online is a great tool to have if you’re doing cloud
development.

As it turns out there are properties on the folders that are important. Drilling
up to the folders in the site, you’ll see the issue. The SharePoint 2013
workflow action/activity for creating a new item is different than 2010.

 

The work around…

Since this works in SharePoint 2010 workflows, the solution is to build a
SharePoint 2010 workflow that does this and call it from the SharePoint 2013
workflow. Thankfully, the new workflow engine can initiate 2010 workflows. The
way I did this was to create a 2010 site workflow in SharePoint Designer first.
That performs the work of creating the document set properly.



When choosing the site workflow, I chose 2010 as the workflow engine.



When editing the workflow, I created an initiation parameter so I could pass the
name of the document set (in this case I called it document set ID).



If you were to run this workflow by itself, you would see this parameter in the
UI for you to type in before the workflow starts. We’ll call this workflow from
another workflow, so we’ll just pass it as a parameter.

Next I created a new item in the host document set library – this is the library
that has the appropriate doc set content attached to it. I changed the content
type and used the workflow initiation parameter for the name of the document set
(I also used a “Request ID” field in my custom content type):











The 2010 workflow looks like this. The new item ID is returned in a variable,
which you can use or ignore:



Next, I created a list-based workflow using the 2013 workflow engine. This
workflow calls the 2010 workflow. See below for the entire workflow:



The highlighted line above shows how we are starting a separate workflow. When
run, we pass in “202” as the name of our document set. The parameter dialog for
the workflow shows how our 2013 workflow wires up values to the initiation of
the 2010 workflow (or any other workflow for that matter).



Again, here we are passing DocSetID, but that’s really just the name of the
document set. It produces the results we wanted too.

This is a pretty neat thing to know as far as reusability goes. There’s a
draw-back here in that we’re depending on the 2010 workflow engine. So future
versions of SharePoint may have issues with this, but this is a decent
work-around for now.


Posted by Unknown at 12:00 PM 8 comments:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: SharePoint 2013, SharePoint 2013 Online, SharePoint Designer 2013,
Workflow



MONDAY, MARCH 31, 2014


DEBUGGING WORKFLOWS IN SHAREPOINT 2013 ONLINE USING AZURE



This is just so cool… You’re now able to debug workflows in SharePoint 2013
online by using your Azure account. Just this past weekend we (Composable
Systems) hosted the Azure bootcamp here in Louisville, KY and I gave a dev talk
on Service Bus. As it turns out, you can use one of your service bus namespaces
to help you develop SharePoint 2013 workflows as well as remote events. Very
timely indeed.

I’m building a SharePoint 2013 App for our largest client, Microsoft. This one
is specifically for the Bing division, which they’ll use internally. I’m using
Visual Studio 2013, SharePoint Online through our Office 365 subscription and a
SharePoint App template. We’ll eventually deploy this to their internal
SharePoint App store.

The first thing you need to do is go into the Azure portal and create a
namespace under the Service Bus category, or choose an existing one you’ve
already created. I just created a new one. No other configuration was needed
here.



Once the namespace is setup, you’ll need to copy the connection string from the
connection settings button near the bottom of the screen.



I just copied the ACS connection string.

Next, open the SharePoint App project properties in Visual Studio.







Now that is setup, I can do a couple of things. I can write details out to the
console and I can set breakpoints. Wait… write to the console? Yep. When you
press play to deploy/run your app, VS.NET starts a console that listens to that
Service Bus.

So in this case, I added a WriteLine activity to my workflow (this comes from
the Primitives section of the toolbox).



This will show up in my console when running the app. Here’s what that looks
like.



And the breakpoint experience is really neat. When it breaks, you can explore
all your local variables. Very handy.




Posted by Unknown at 10:46 PM 6 comments:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: Azure, SharePoint 2013, SharePoint 2013 Online



TUESDAY, MARCH 4, 2014


THE FUTURE OF INFOPATH FORMS



Probably one of the most important topics to Composable Systems, and myself
personally, at the SharePoint Conference (2014) is the future of InfoPath Forms.
InfoPath is supposedly gone as a product… That means in about 10 years, we’ll
have to deal with migrating our forms to some other tool or set of tools.

Relax. That’s 10 years. InfoPath is going to be supported in its current form
and will still be part of the next version(s) of SharePoint. Forms hosted in
SharePoint will still work. The app will work on the desktop as well. So we’ll
have time to migrate to a new solution, but we shouldn’t wait too long to
re-think our forms. Having said all that, the future is still not too clear. At
the SharePoint Conference today, Microsoft said that they’re very much in flux
here and are looking for help from the community to guide this. They said
there’s a lot of work going on here within Microsoft, but there’s nothing ready
to ship anytime soon. So there was no big announcement. It’s not what I wanted
to hear, but at least they’re transparent in their position here.

Despite this, the team gave a good classification of the different types of
options/tools available to deal with this. Here are the items they covered. Some
things are available today, others are coming in the future.

Excel Surveys

This has already shipped with SharePoint. It’s often overlooked and most people
haven’t even heard of this. This is actually a great solution for simple surveys
and forms. There is a simple designer to add as many questions, of varying type,
to the form. These simply become columns in Excel. And you get to share the
survey URL for people to fill out. When results come in, they go directly to the
spreadsheet – and in real-time. To create one, just choose new “Excel Survey”
from within a document library.

List Forms

This is new stuff. It wasn’t really a product announcement as in replacing
InfoPath, but it did put a nicer experience on top of a list. These are MS
Access-based forms that sit on top of a list. Before we go too far here, this is
just the form part of MS Access and is entirely web-based. It’s based on HTML5
and is initiated using the ribbon while editing a list – there is a new “design
form” button that sits right next to the InfoPath button. It’s a fast and
flexible design surface which allows drag/drop support of labels and fields. You
can re-size and re-position. It’s just form elements for the current list
though. You essentially create a new view. It’s not as comprehensive as I would
have hoped. This will ship in SharePoint online within the next 3-6 months.

Structured Documents

This is another scenario where Word documents are used as high-fidelity
documents which gives users a more WYSIWYG experience. These are fillable word
documents where the form fields can be edited and/or filled out. It meets the
need of an online as well as offline scenario. These most closely resemble the
InfoPath forms, but are not nearly as complex. They’re just for filling out and
capturing data. Also, the data is kept in the Word document, so it makes for a
good archival story. This functionality is about a year off.

App Forms

These are the most complex forms. These are based on MS Access online which
allows for a relational and fully transactional database behind the scenes. By
the way, the new MS Access online databases are based on SQL Azure. So it’s
going to be scalable, capable and reliable. This is currently shipping in the
online version.

So, this is sort of like the Shuttle program being shut down without a real
clear path to get to the space station. Not what I wanted to hear – I really
wanted a cool HTML5 based application that did what InfoPath did, but without
all the strings attached. I guess we’ll wait and see on this – we’ll keep you up
to date on this. We’ll also deal with this on a case-by-case basis. Sometimes
using InfoPath, sometimes creating our own HTML5 forms.


Posted by Unknown at 1:21 PM 1 comment:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: SharePoint 2013



SATURDAY, AUGUST 1, 2009


ODD ERROR WHEN RETRIEVING ITEMS FROM AN SPVIEW



When attempting to retrieve items from an SPView programmatically, you cannot
reference fields by name or by their ID.  Note, I’m using MOSS 2007 with SP2. 
So here’s the code that causes the issue (and resulted in over 3 hours of wasted
time)…

> Guid listId = new Guid(...);
> Guid viewId = new Guid(...);
> 
> SPList list = SPContext.Current.Web.Lists[listId];
> SPView view = list.Views[viewId];
> 
> SPListItemCollection filteredItems = list.GetItems(view);
> 
> foreach (SPListItem item in filteredItems)
> {
>     Response.Write(item["Title"]);  // THIS FAILS
> }


And you’ll see this error:


Exception has been thrown by the target of an invocation. --->
System.ArgumentException: Value does not fall within the expected range. at
Microsoft.SharePoint.SPFieldMap.GetColumnNumber(String strFieldName) at
Microsoft.SharePoint.SPListItemCollection.GetRawValue(String fieldname, Int32
iIndex) …


Thankfully, the SPView object exposes a Query property which is a string that
contains the CAML that filters list items.  Using this property, you can just
create your own SPQuery object and retrieve the items from the list.  The
following code has this modification.


> Guid listId = new Guid(...);
> Guid viewId = new Guid(...);
> 
> SPList list = SPContext.Current.Web.Lists[listId];
> SPView view = list.Views[viewId];
> 
> SPQuery query = new SPQuery();
> query.Query = view.Query;      // GET THE QUERY PROPERTY FROM THE VIEW
> 
> SPListItemCollection filteredItems = list.GetItems(query);
> 
> foreach (SPListItem item in filteredItems)
> {
>     Response.Write(item["Title"]);
> }


Hopefully, this saves you some time.


Posted by Unknown at 11:34 PM No comments:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: SharePoint 2007



TUESDAY, JUNE 30, 2009


DOCUMENT LIBRARY ICONS MISSING



Here’s something to keep in mind as you provision document libraries inside
SharePoint.  You can provision document libraries through both the web (site)
and site (site collection) scoped features.  The way you would do this is
through use of the ListInstance element similar to the following:

<ListInstance
  Id="Expenses" Title="Expenses" OnQuickLaunch="False" RootWebOnly="true"
  FeatureId="00BFEA71-E717-4E80-AA17-D0C71B360101"
  Description="Contains expense documents."
  TemplateType="101" Url="Expenses">
</ListInstance>


Unfortunately, when provisioning document library instances from site collection
features the icons appear to be missing.  In the object model, which you can’t
change after the fact, the ImageUrl property is empty.  If you look at the “View
all site content” link, you’ll see what I’m talking about.





This is just something to be aware of.  It may not be a show-stopper, but it’s
an inconvenience to your users.  I’d recommend provisioning your lists as site
features (at the Web scope).  It may mean more features to manage, however.


Posted by Unknown at 12:46 PM No comments:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: SharePoint 2007



THURSDAY, JUNE 11, 2009


KEEP SITE DEFINITION IDS UNIQUE



This recently bit me.  I had two different site definitions.  They had two
different webtemp xml files, of course.

Here’s the first one:

<?xml version="1.0" encoding="utf-8" ?>

<Templates xmlns:ows="Microsoft SharePoint" >
  <Template Name="STORESITEDEF" ID="10010">

...

The second looked like this

<?xml version="1.0" encoding="utf-8" ?>

<Templates xmlns:ows="Microsoft SharePoint" >
  <Template Name="MARKETSITEDEF" ID="10010">

...

When I went to create my site, I kept getting this error:

The template you have chosen is invalid or cannot be found...

I incorrectly assumed that the ID was only relevant within a given site
definition – why this wasn’t a GUID, I don’t know.  Anyway, I changed one of my
IDs to be different and after an IISRESET all is well.


Posted by Unknown at 11:14 AM No comments:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: SharePoint 2007, SharePoint 2010



TUESDAY, JUNE 2, 2009


ALWAYS CAPITALIZE (ALL-CAPS) BOOLEAN VALUES IN CAML



So here I was, late at night, banging my head against the desk trying to figure
out why my a custom field’s custom property wasn’t hiding when I clearly stated
Hidden=”true”.  As it turns out, you need to specify the uppercase value for
that boolean or it simply won’t work.  There’s no error; it just doesn’t hide. 
Here’s a snippet of code where this bit me while developing a custom column
using the ProperySchema section to allow additional settings to be used for the
field.

<FieldTypes>
  <FieldType>
    <Field Name="TypeName">CustomColumn</Field>
    <Field Name="ParentType">Note</Field>
    <Field Name="TypeDisplayName">My Custom Column</Field>
    <Field Name="TypeShortDescription">My Custom Column</Field>
    <Field Name="UserCreatable">TRUE</Field>
    <Field Name="ShowOnListCreate">TRUE</Field>
    <Field Name="ShowOnSurveyCreate">TRUE</Field>
    <Field Name="ShowOnDocumentLibraryCreate">TRUE</Field>
    <Field Name="ShowOnColumnTemplateCreate">FALSE</Field>
    <Field Name="FieldTypeClass">ACME.SharePoint.Blah.CustomField, 
       ACME.SharePoint.Columns, Version=1.0.0...</Field>
    <PropertySchema>
      <Fields>
        <Field Name="MySetting"
               Hidden="TRUE"
               DisplayName="My Setting:"
               MaxLength="500"
               DisplaySize="40"
               Type="Text">
          <Default></Default>
        </Field>

   ...


As you can see Hidden is set to “TRUE.”  “true” simply does not work.


> What’s funny is that the WSS.XSD gives you intellisense in VS.NET (in most
> areas) for the following options for boolean fields: true, false, True, False,
> TRUE, FALSE.  Ok.  Why?


This was just one case where my choice of case caused an issue.  What about
everywhere else?  So proceeded to tell my colleagues, including Bryan Phillips,
about this oddity with hiding properties of custom fields.  He said that he
always uses uppercase.  Not only for custom columns, but for everything.  I’ve
typically used lowercase since it seemed to be close to my c# practices. 
However, from now on, I’m going to capitalize my boolean values.


Posted by Unknown at 11:17 PM No comments:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: SharePoint 2007, SharePoint 2010

Older Posts Home

Subscribe to: Posts (Atom)



ABOUT ME

Unknown View my complete profile



BLOG ARCHIVE

 * ▼  2014 (3)
   * ▼  May (1)
     * Creating a Document Set with SharePoint Designer 2...
   * ►  March (2)

 * ►  2009 (10)
   * ►  August (1)
   * ►  June (3)
   * ►  May (1)
   * ►  April (4)
   * ►  March (1)

 * ►  2008 (7)
   * ►  December (1)
   * ►  June (2)
   * ►  May (3)
   * ►  February (1)

 * ►  2007 (6)
   * ►  December (1)
   * ►  September (2)
   * ►  August (3)





Simple theme. Theme images by A330Pilot. Powered by Blogger.



Diese Website verwendet Cookies von Google, um Dienste anzubieten und Zugriffe
zu analysieren. Deine IP-Adresse und dein User-Agent werden zusammen mit
Messwerten zur Leistung und Sicherheit für Google freigegeben. So können
Nutzungsstatistiken generiert, Missbrauchsfälle erkannt und behoben und die
Qualität des Dienstes gewährleistet werden.Weitere InformationenOk