none
How to use WebMethod.Put? RRS feed

Answers

  • Actions aren't supported in the Power BI or Power Query environments as they are intentionally side-effecting.
    Friday, September 21, 2018 4:35 PM

All replies

  • Seems to be used in combination with the function WebAction.Request to perform PUT requests against an API. So far we were only able to do POST and GET request, so a PUT (basically an update to a record) would be pretty cool for something like the CDS or if they plan to integrate Power Query with Flow for example.

    PQ now also has:

    • WebMethod.Delete
    • WebMethod.Head
    • WebMethod.Patch

    and even explicit ways to tell if it's a GET or POST:

    • WebMethod.Post
    • WebMethod.Get

    but all they do is simply translate to a "text" value that can be used in that WebAction.Request.

    EDIT: That's my best guess. I haven't actually tried this function yet

    • Edited by Miguel Escobar Friday, September 21, 2018 3:36 PM Waiting for Ehren to confirm
    Friday, September 21, 2018 3:35 PM
  • Actions aren't supported in the Power BI or Power Query environments as they are intentionally side-effecting.
    Friday, September 21, 2018 4:35 PM
  • Actions aren't supported in the Power BI or Power Query environments as they are intentionally side-effecting.

    Hi Curt,

    I'm unclear about what you mean by the statement. Any kind of I/O operation would be side-effecting, and it doesn't follow that because such functions create side effects, these functions shouldn't be part of the Power BI or Power Query environment.

    1) Because M functions evaluate their parameters eagerly, it means that you can create intentional side effects. A good example was shown in a previous post by Ehren, which demonstrated how one can send a logout request to a service. 

    https://social.technet.microsoft.com/Forums/en-US/27511cba-4a87-4e80-991a-7b0a2b07f51b/run-logout-script-as-part-of-the-query?forum=powerquery

    One can argue that such use of a function is not kosher; but unless there is a better alternative, and one can point out the downside of the provided solution, it seems to be a safe use of side effects.

    2) Haskell is considered to be the purest commercial functional language on the planet. Yet Haskell has to deal with side effects for I/O operations. However, there is a clear demarcation between Haskell's pure functions and its I/O monad functions. You have to go through an "interface" to connect the result of an I/O operation with a non-side effecting function that may operate on the result. The M action functions what were once listed (but not documented), are equivalent to the Haskell I/O monad. So why shouldn't they be part of Power BI/Power Query?

    3) Section 3.5 of the Formula Language Specification details circumstances under which side effects in M can occur. Whether you consider such circumstances intentional or not, they will occur, and will have to be dealt with.

    4) Come to think of it, aren't all M functions that access external data side effecting? For example, a call to a database to return a query is affecting an entity outside of the function itself.

    Sunday, September 23, 2018 5:02 PM
  • Yes, I probably should not have argued this from the perspective of side-effecting. Say, rather, that we have a model which tries its best to ensure that your queries will not modify data in the systems it accesses. By contrast, actions are intentionally designed to mutate data.

    As you say, actions are patterned after Haskell's monads. Your query returns an action -- which may itself consist of a set of actions that have been built up -- and then the query is finished without any changes having happened. In an environment which supports writes, there's an extra step at the end where the action is finally executed.

    Tuesday, September 25, 2018 7:20 PM
  • Yes, I probably should not have argued this from the perspective of side-effecting. Say, rather, that we have a model which tries its best to ensure that your queries will not modify data in the systems it accesses. By contrast, actions are intentionally designed to mutate data.

    As you say, actions are patterned after Haskell's monads. Your query returns an action -- which may itself consist of a set of actions that have been built up -- and then the query is finished without any changes having happened. In an environment which supports writes, there's an extra step at the end where the action is finally executed.

    Thanks for the great response. I suppose that I was thinking ahead to a future where Power Query could do external writes, and perhaps perform other useful actions. However, I think that you've made it clear that such functionality is unlikely to ever be included in PQ.
    Tuesday, September 25, 2018 7:49 PM