This past week, I did my first deployment using the K2 Cloud Package and Deployment (P&D) tool. I had problems during my first two attempts, but won the day on my third try — with some help from network analysis software. Here’s how.
I live in Texas. For the past few days, we’ve been getting storms — some violent — at around 3 AM. If the storms are bad enough, I’ll have a headache all day — and I don’t mean from the barometric pressure.
File this under “Learning the Hard Way” and “Stop Messing With Your Browser Settings.”
I hadn’t. Not really. Until today.
I’ve a client who’s forcing me to learn — my main contact isn’t familiar at all with K2, so I’m getting asked lots of questions. Today, he wanted to give a person access to the K2 Designer. I had no idea how to do it, but I offered to dig into the server’s configuration files to figure it out.
Here’s what I found.
Given source and target systems within a company’s intranet. The source system is a SharePoint server, though which K2 is surfaced. The target system is also a SharePoint server, through which Microsoft Project Online is surfaced. The challenge: to access the data on the target system through the use of REST services only — without a JSON descriptor.
Things just BLEW UP the other night. I connected to the development server, opened my solution in K2 Studio, started to edit, and BLAMMO! Everything went black.
Administrators had to rebuild my blown profile on the server. Once I was able to get into the desktop again, I figured I should have been able to drop shortcuts to K2 Studio and Visual Studio onto my desktop. No big deal, right?
I was able to open K2 Studio, load my solution, but was surprised to see that the solution was not connected to the (local) development environment.
I was even more surprised when anything I tried to do that was related to the server (like open an IPC, for example) yielded a nasty “Primary Credentials Not Authenticated” exception that threw me out of K2 Studio completely.
Had this happen today: The business contacted me because they had a worklist item they couldn’t release.
As I was walking our business users through the role management features of the K2 Workspace, they lamented that they K2 didn’t give them visibility inside of the Active Directory groups which are assigned to various roles. My quick solution was to provide them with a PowerShell script which would give them the insight they were looking for.
I was recently asked if one can determine whether a specific person has a specific process instance in his/her worklist. The answer is yes — an administrator can do this from the K2 Workspace if some attributes about the process instance are known.
That’s a stupid slug. Oh well. Moving on…
How can you tell what people have been assigned to a particular AD group?