Open Ticket Migration

WEVO Group has developed an Open Incident Migration Process, click link to watch video, for ServiceDesk 7.5. This Open Incident Migration Process facilitates the recreation of open ServiceDesk Incidents, at stage 1, from your 7.1 Sp2 environment to your new 7.5 environment. Used in conjunction with Symantec's closed Incident Migration process you will be able to easily move your incidents over from your previous version of ServiceDesk to your new 7.5 environment. The biggest benefits of this process are:

• Ability for your technicians to use the 7.5 environment solely on the first day of your cutover.
• Incident reporting on your 7.5 instance will reflect all historical data quicker.
• Provided Admin Portal will allow your technicians to view and work un-migratable incidents on you Sp2 environment from your 7.5 environment.

This process is a benefit of using WEVO Group as your SD7.5 implementation partner. I will explain stage 1 incidents as that is a term that we developed at WEVO. Stage 1 incidents are incidents that have not been escalated or had sub tasks created for them. They are basically incidents that are at their first dialog workflow or human interaction. Once an incident has moved past their initial routing point, been escalated or had sub tasks created for them, it is impossible to migrate them to their exact same stage in the 7.5 environment. This is because we are unable to edit the ServiceDesk's Incident process, because in 7.5 all ITIL processes have been locked. Remember, we provide you with an admin portal that allows you to work those few incidents that couldn't be migrated from your 7.5 environment.

For those of you who are used to the earlier versions of ServiceDesk and being able to edit every process this may come as a shock to you. Basically Symantec has decided, and I agree, that the only way to provide ServiceDesk customers with a more product like feel and easier upgrades is to lock the core processes. They have also provided the rules engine in 7.5 that allows you to configure the Incident and Change processes from the process manager instead of having to dive into the code, as you used to. The downside for workflow guru's is less customization ability and the upside is easier upgrades to new versions. There are ways to make customizations through the ORM and through the Process Type Actions but we will get into those in another blog post.

The WEVO Group's Open Incident Migration Process is provided for free to WEVO clients that engage us to make their ServiceDesk 7.5 transition. If you would like more information about our SD7.5 Open Incident Migration Process, please contact Erik Tversland or fill out our info request form.

Using the ORM Data Type in Symantec Workflow

The ORM data type (better known as a “user-defined type with DB mapping”) in Symantec Workflow can be a useful way to automatically tie together your own custom data between workflow processes and Process Manager. It can also quickly become a headache if you use it in the wrong circumstances. I will briefly discuss how to identify exactly which circumstances are ill-advised to use the data type.

One issue we consistently encounter when creating a DB mapping is the translation of the ‘text’data type. It has become clear that although a full ‘text’ field is desired in Workflow, it is mapped to the database to be an nvarchar(255); namely, of finite length. This becomes an issue when requiring fields in our data type which may contain ‘description’ or ‘comments’ or ‘details’ that could easily extend beyond this character limit.

One solution we found is to manually edit the data type of the columns in the database to be nvarchar(MAX) after the database is created. However in some circumstances, usually when accessing a profile of the data type or encountering a mapping error, Workflow will automatically create a new column with type nvarchar(255) (which subsequent ORM data instances will use), and alter the old column heading to be “_old_”, still with type nvarchar(MAX). Clearly, this can cause unexpected and undesirable inconsistencies in the database structure.

It is also important to realize the context in which the ORM data type is used best: In ServiceDesk, where a single data instance (such as an incident) is related to a single task. Typically, you can simply add a new data element of the ORM type, map data to it, then follow up with a Save External Data component and Workflow will automatically write and sync changes to the database.

If you attempt to maintain and update multiple instances in a collection of an ORM data type, Workflow cannot guarantee the persistence of those entries, because Workflow can reference only a single instance to sync and update with. Consider this simple example with two instances of an ORM data type, abstractly labeled “A” and “B”. If changes are made to instance A, Workflow cannot ascertain if the intent of the user is to update the data in instance A or overwrite the data in instance B. This usually results in unstable behavior, which causes a breakdown of data integrity.

As previously mentioned, the ORM data type works best when a single instance can be tied to a single task, such as in a Dialog Workflow component. While inside of the event configuration of a dialog, all changes to the instance are saved automatically (without the need of database writes or the Save External Data component). Be aware that bad external references to the database, which can occur if some of the above practices are conducted, are cleaned up at the conclusion of the dialog component.

Finally, it is important to ascertain the purpose and function of using an ORM data type. As previously mentioned, using an ORM data type can easily tie data from your Workflow processes directly into Process Manager to be used in reports and task data, which is accomplished through a process profile. Once the profile is created, it is easy to create custom process view pages that can display this data to be readily accessible by the user. However, if the user will sparingly be using the process view page or the Process Manager web portal, it is not always practical to set up your process with an the ORM data type.

In summary, the ORM data type is a powerful tool in Workflow that can easily expose data to be accessible in Process Manager. However, be aware that trying to implement large text fields in the data type causes the database structure to become unstable. Additionally, using a single instance of your data type in a process is ideal; a collection of instances can result in errant process behavior and a breakdown of data integrity. This is why it is important to understand the context of your Workflow process and use the ORM data type if your users will be accessing process view pages. In conclusion, following these advisement's will help to ensure your Workflow processes use the ORM data type properly and to its maximum benefit.

If you have any questions please feel free to comment below, fill out our info request form, or reach out to me directly.

Thanks for reading,
Justin Searles 
justins@wevogroup.com

Symantec Workflow Managed Services

As Symantec Workflow developers we know that it's a trial and error type of solution. There are a million (maybe not a million, but you get the point) ways to accomplish the same end result. This is great in the sense that the tool allows for a lot of creativity and flexibility when developing processes, but it can also be very frustrating when you are trying to figure out how to accomplish a specific task. Documentation for the tool is somewhat scarce and/or vague so most users rely mainly on the user community such as Symantec Connect or Workflow SWAT. Both of which can be great resources, but have their disadvantages as well.

Symantec support, and rightfully so, can not support/troubleshoot custom processes or assist with custom process development. With the tool being as flexible as it is how could Symantec train their support staff to be able to troubleshoot every single scenario that could pop up in a Workflow development project? Impossible at best. This is very common with all software companies, custom changes are not supported.

Searching Symantec Connect can furnish some great information, but it is time consuming and you usually have to read through a lot of articles and posts before you get to your specific topic. Then you have to try the solution you have found in your environment. Workflow SWAT has some great video learning tools, but not specific troubleshooting information.

WEVO Group is now bringing a custom workflow support solution to all Symantec Workflow and ServiceDesk 7 clients. Through Workflow Managed Services, by WEVO, clients can now take advantage of the following:

• On-Demand Workflow Expert to answer quick questions or to review development
• Custom Workflow Process and ServiceDesk 7 customization support
• Monthly Environment Health Check*
• 24x7x365 Pro-Active Error Monitoring**

Plans are very flexible and affordable. Contact WEVO for more information or go to http://managedservices.wevogroup.com. As always questions are welcome directly through the blog as well.

* qualifying plans only.

** qualifying plans only. Additional setup engagement required.