Complex data types make our lives a whole lot easier in Workflow Solution, and it's critical to use them skillfully in our Workflow projects. This 13-minute video walks you through the process of creating your own complex data type as part of a very basic hardware request project. Once we create the custom data type, we will then use it to structure several pieces of information from a hardware request into a single variable, which we will then display in the body of an email and on a web form for review. Keywords: Complex data type, create integration libary, user defined type, generator, webforms, add new data element, grid component, browse data, array, send email, html table from collection
00:13:43
I'm glad you mentioned writing your complex data types out to database for audit purposes and future reference etc. This is because i'm keen to do this myself. To illustrate what I mean, I'll use the Customer Servey in SD7 as an excellent example:
In the workflow I'm building, I've:
This is a web forms project which I will publish to the servicedesk Service Catalogue.
What I need to do now, is add in the workflow a component or set of components, which effectively:
Write the content of the user entered variables into a (in sql speak) 'table' if you like, so the user entered data is committed to the Ensemble database somewhere; then
have this set of components somehow create a join (in sql speak again) from my newly commited data, to the Incident record I've created.
This is because I need to then write some custom Smart Tasks which will want to draw on the data taken from the form (now associated with the incident through some kind of join) in order to perform further actions as a ServiceDesk technician (ie retrieving approvals for the application using the affected user from the form by linking to the stored data).
Given what I've done so far, can you suggest any additional components to my workflow to commit this data to table (or xml doesn't really matter what medium I assume) and create the join. I am also unsure where these components should sit - ie at the start of the workflow or at the end. It's worth noting I think that the new ticket is generated at the end, so I'd expect one or the other of these components would need to be triggered after the ticket is generated...
I hope this makes sense, my knowledge of how to store data to database, linking it to a ServiceDesk Ticket, and making it accessible to other workflow projects after that, is a little vague at my current knowledge level.
I think if I can sort this theory out, I can leap ahead with our user interaction from within our Incident records.