EPiServer Workflow Replacement : Step 4–Rejecting Pages Programmatically

This is the fourth in a series of posts about how my company built a replacement workflow platform for EPiServer. Why we chose to do this is explained here: http://world.episerver.com/Blogs/Hans/Dates/2012/4/EPiServer-Workflow-Replacement--Step-1Explanation-and-Disabling-Edit-Tab/

I’ll go on record here and say that I don’t love that this is done through the database. This is why SDK’s are made..and this entire process should be able to be done by using the PageProviderBase.SetPageStatus method as described here : http://sdk.episerver.com/library/cms5/html/M_EPiServer_Core_PageProviderBase_SetPageStatus.htm

….. but, as I mentioned already, it doesn’t work – so we have to go right into the database. Any time you do this, make sure you know what you’re doing – there’s a good chance you’re mucking with something that isn’t meant to be touched. I take no responsibility for you using this, you’ve been warned*!

(*that being said, we’ve been using this in EPiServer CMS 5 for three years and EPiServer CMS 6 for several months, across different environments, and haven’t had any problems)

Here’s our RejectPage method. Basically, tblWorkPage seems to have all of the page status information – and all it really  needs is the WorkPageID (pkID) and the PageLinkID (fkPageID) values, and all we do is set ReadyToPublish back to 0, which in EPiServer terms basically means that the page is “Not Ready”.

        protected void RejectPage(PageData pageToReject)
        {
            SqlConnection SQLConnection = new SqlConnection();
            string UpdateString = "UPDATE tblWorkPage " +
                                "SET ReadyToPublish = 0 " +
                                "WHERE (pkID = " + pageToReject.WorkPageID + " ) " +
                                "AND (fkPageID = " + pageToReject.PageLink.ID + " )";

            String strConnString = ConfigurationManager.ConnectionStrings["EPiServerDB"].ConnectionString;
            try
            {
                SQLConnection.ConnectionString = strConnString;
                SQLConnection.Open();
                SqlCommand mySqlCommand = SQLConnection.CreateCommand();
                mySqlCommand.CommandText = UpdateString;

                mySqlCommand.ExecuteNonQuery();

            }
            catch (Exception ex)
            {
                if (SQLConnection != null)
                    SQLConnection.Dispose();
                ErrorHandler.HandleError(ex);
            }
            finally
            {
                SQLConnection.Close();
            }

        }

We, of course, are an Oracle shop, so most of our instances are actually using the following variant instead:

      protected void RejectPageOracle(PageData pageToReject)
        {
            OracleConnection ORCLConnection = new OracleConnection(strConnString);

            string UpdateString = "UPDATE tblWorkPage SET " +
                            "ReadyToPublish = 0 " +
                            "WHERE pkID = " + pageToReject.WorkPageID +
                            "AND fkPageID = " + pageToReject.PageLink.ID;
            try
            {
                ORCLConnection.Open();
                OracleCommand oracleCommand = ORCLConnection.CreateCommand();
                oracleCommand.CommandText = UpdateString;
                oracleCommand.ExecuteNonQuery();
            }
            catch (Exception ex)
            {
                ORCLConnection.Close();
                ErrorHandler.HandleError(ex);
            }
            finally
            {
                ORCLConnection.Close();
            }
        }

…but you get the idea. In the next post I will discuss how we get around those pesky “Save and Publish” buttons which let people circumvent our new Workflow implementation.