Using SharePoint Designer 2013 Workflow to copy file via REST on Office 365

This is a bit of trial and error, but works very well at the end, so I want to publish this and share the syntax.

 

Related References:

 

I will tackle the next step.  How do you call a POST REST service, with the CopyTo function on SPFile.  http://msdn.microsoft.com/en-us/library/ms455020.aspx

The flexibility is that you can easily tweak the urls and essentially allow your workflow to copy files anywhere.

 

Step 1.  Understand the correct URL

 

Put this into your browser's address bar (this executes a GET request):

image

No good.  Need POST.

 

Step 2.  Make that SharePoint Designer 2013 Workflow

 

  1. First step, with the POST call, we need to add a Request Header for Accept: application/json; odata=verbose
    Put this in a dictionary variable.

    image
  2. Second step.  Call Web Service!
    image

    You need to set up Request Headers as well.  This has to be done via the Properties, since it's not a link that's shown.  Set this to the dictionary created in the previous step.
    This step is the same as mentioned in Adrian Fiechter's blog.

    image
  3. You should capture the ResponseContent, and add an additional action to log it to History
    The Stage ends.  Go to End of Workflow.

    image

  4. The whole thing, in 3 lines:

    image

Step 3.  Run it.

 

image

Here's me starting the workflow on the top1.png file.

 

image

The top1.png is copied to top2.png!  Interestingly, it's copied the Call Workflow "workflow status" column.  Both links (which is a lookup field) go to the same workflow.

 

image

This is the workflow history. 

Notice that the CopyTo method returned void (null) in this case.  Should there be an error, you'll see it logged here.

 

That's all!  Hope you find these steps useful.

InfoPath's future and what everyone's saying

dontpanic

 

Andrew Connell

  • "the future is unclear at best, realistically pessimistic and a dead-end at worst"
  • "I do not use InfoPath any more & I do not recommend people use InfoPath going forward"

http://www.andrewconnell.com/blog/now-infopath-is-dead-rip-infopath-but-now-what

http://www.andrewconnell.com/blog/my-thoughts-infopath-2013-the-future-of-infopath

 

Mark Rackley

http://forms7.codeplex.com/

 

Corey Roth

  • Lists a great list of feature sets for the future Forms solution
  • Suggest: wait and see SPC348

http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2014/01/31/what-a-developer-wants-in-a-post-infopath-world.aspx

 

Jeremy Thakes

  • "I  found that if  you used InfoPath in your Organization to empower Information Workers to build their own forms, a lot of the times they’d hit the 80/20 rule and then hand it off to developers who would have to fix them or complete them."
  • Suggest: ISV Nintex Forms

http://www.jeremythake.com/2014/01/microsoft-confirm-infopath-2013-is-last-release-of-the-product/

 

Microsoft

  • InfoPath is dead.
  • Long live Forms:

http://www.sharepointconference.com/content/sessions/SPC348

 

Patrick Halstead

I like Patrick's coverage the best, probably because this is his bread and butter.  He has been thinking about this and planning for a while. 

His upcoming webinar series will cover the various approaches to deal with the data that's currently in the forms:

  • Status Quo: keep same format (XML): Formotus, ServBus, Qdabra eForm Viewer
  • Hybrid (SharePoint List): move the form's data into SharePoint Lists, then use SharePoint list forms
  • Convert to ISV: Nintex, K2, Adobe, Salesforce
  • Custom development (database): extract data into database, then build pages and use full set of controls

http://www.youtube.com/watch?v=Z_rhNrFx5D8 [After InfoPath: Planning your Form's Future] 

 

I say: Please Don't panic.

I'm waiting to see:

  • Qdabra eForm Viewer (cheap /  free / open source?  does the user need to do anything?)
  • Nintex Forms (roadmap, feature compatibility)
  • Microsoft's SPC348 (upgrade roadmap?  future support?  feature compatibility? could be the most expensive path)

I'm sure everyone will have a lot to say in time for the SharePoint Conference.  Stay tuned.

Building No-Code Sandbox WebParts for the past, present and the future [Proposed Session Outline]

 

[Previous Working Title: Build amazing web parts using only JavaScript and evolving your code with any version of SharePoint]

I've modified the session title based on recent events.  Namely, this big one: http://blogs.msdn.com/b/sharepointdev/archive/2014/01/14/deprecation-of-custom-code-in-sandboxed-solutions.aspx 

 

In this session I really want to talk about investing in a safe, new technology (JavaScript) that isn't going away anytime soon, and have it being useful for you, today, regardless of whether you have/are/won't migrate to SharePoint 2013 anytime soon.  I want this to be a talk about the timelessness of the technology, but also the ever-changing landscape.  I hope I can get us there.  I think it is awesome.

 

Session Description

SharePoint is an evolving platform: in 2007, we were all building farm web parts. Then in 2010, we were introduced with sandbox web parts, with the beginnings of the client side object model. In 2013, we are looking at the evolved app model, with a super-charged REST service.

As developers, while it is great to learn about what's coming down the pike, it feels extremely frustrating not knowing what to learn, or attend a session and learn a technology that you can’t put to use because you don’t use the latest and the most cutting edge in your organization.

Let’s take a step back, let’s look at how to build a web part using only JavaScript. Let’s separate the UX from the logic. Then let’s plug in different types of CRUD code to work with different versions of SharePoint, across different data sources: lists, search or user profile.

This session is about learning how to use JavaScript to build amazing web parts, regardless of what version of SharePoint you have.

 

Session Outline

 

  • What is in a little WebPart
  • Where do you run your code
    • Running the code on the Server (.NET)
    • Running the code on the browser (JavaScript)
  • Choices:
    • SPServices
    • CSOM
    • REST (listdata.svc)
    • REST (_app)
  • Platforms
    • SP2007
    • SP2010
    • SP2013
    • Office 365
  • Framework Considerations:
    • Plain JQuery
    • KnockoutJS
    • AngularJS
  • Adding Value:
    • TypeScript (Syntax, Intelli-Sense)
    • Jasmine (Unit Testing)
  • Where are we, where are we going
    • Where should we be?
  • Demo
    • Can't possibly cover everything and still have a working demo, can I?  Though I do love having demos to show people at the end of a session.

 

This is a session in ongoing development.  But I wanted to throw out the outlines and get some feedback on what do you want to see?  And what do you NOT want to see.

Let me know below!