Last month, I introduced a new path for myself in the Sequel - https://blogs.sap.com/2018/08/13/the-abap-detective-sequel/ I've moved to a work phase where instead of supporting an impending database platform migration (delays until happiness in testing) I'm doing an "as-built" documentation exploration coupled with proposals for enhancement to the tasks inherent to my quasi/non-governmental agency, namely a social event calendar. And maybe a tech road map.
Not an environmentally friendly way for me to do this, er, paper drawing but oh well, better to share my style than not. As I have no access to MS Visio, the tool I'd use in the past for process mapping, I went with the tool already widely used by the group, Open Office drawing. There's probably some way to move renderings between the platforms, not to mention the business processing modeling languages popular in that channel.
I'm searching for drawing templates (read: clipart) for people/teams, for folders, and even, gasp, 3-rin binders. Arrows and call-outs are looking good or will be. SAP Workflow gods and goddesses will recognize similarities in the notation, at a base level.
The primary objective I've taken on is identify where there is physical paper flow that could be automated/digitized. Before recommendations come study. Sponsors, or event locations, have specific detailed data, as illustrated by a classic handwritten form from a few decades back (at most).
I notice little things like the mailing address differing from the event location and wonder what would we ask for if this planning activity started today (probably ICS file comes to mind?)
When I think about how these activities differ from business processes is these are primarily social with a necessary administrative side. Non-profits could be businesses from tax, finance or other angles. Maybe service delivery processes is more apt.
Back to the technical database level for a bit. The sponsors, as they're called, could be venues or vendors or clients, whatever. Keys functions are a communication research step where upcoming sessions are recorded. Of course, things change, so there's a periodic update/refresh phase. The document printed below is a recent generation.
In the 70's this would be called a "turnaround document". Sent out for data collection, returned to a central office for data entry. Probably still are.
Only fields from the organization table are shown, not prior history or current events. This is used to poll by phone (as far as I know now), which leads to questions on whether email, spreadsheet exchanges or maybe even a web presence (unlikely for this side to produce but not unlikely to consume). There's a confirmation step/process, as there should be. More on that in the future.
Another way, if I may digress a bit, of thinking about service organization flow takes me back to waste processing methodologies, essentially modelling natural decay or biological processes. I need to share the ideas as documents etc. alongside diagrams as simple as I can produce.
One critique from a predecessor in my role was the current published calendar text is 'free form' not lending itself to chronological sorting and other boring needs of life in the event trade.
Enter the VCAL file, or as rookie ABAP detectives call them, ICAL. The legacy data content has values such as:
Humans pick up what this means, hopefully without a second thought. Doesn't meet the VCALENDAR file expectations. Newer software might guess right, but for now, assume these will not compute.
So, new database table to match the old one per event/show detail. Can't easily extend the extant data structures since a calendar invite or series thereof, due to overload of the data cells. For example, the above one row showing August 17th through the 19th would be 3 calendar entries to that one line. I'll leave out the schema scheme parts.
My first take has minimal fields to get acceptable calendar invites, using Google and Apple devices. One of the Perl examples that got me bootstrapped is an advent calendar [ e.g. http://perladvent.org/2017/ and http://perladvent.org/2014/2014-12-18.html and of course http://perladvent.pm.org/2007/1/ ]. With minor headaches, I was able to connect these libraries to an ODBC driver (my old fave Perl DBD and DBI ) connected to a couple MS SQL databases. If you didn't follow that last sentence at all, bear with me.
Looks odd because it's SQL inside a Perl program. Or not so odd I imagine.
The "H" search match is one of those letters noted in the first couple flow charts above as a data classification, albeit arbitrary if not capricious. This is merely a stub/proof of concept. The working versions would join more relevant and less redundant data.
Calendar files can have a single event, or multiple. This seems directly useful for plays, say, that run through an engagement, as opposed to another opening, [of] another show.
The invite dissemination plan is another future direction to be determined; while email attachments are the norm for many, and should kind of just work, making clickable links seems straightforward enough. I'm ignoring possibly critical infra chunks like serial IDs, timezones (which had interesting experimental case failures right quick).
A more polished example snippet:
I chopped off the subsequent events, just to show the basic groups of data (header and detail in a sense).
Whether this work "goes to production" quickly or languishes time will tell (heh). Meanwhile I've learned some new wrinkles in connecting people to places where things happen, and made my life easier by knowing when I'm supposed to be somewhere.
Future:
Future 2:
Future 3:
Grateful thanks to susan.keohan for brainstorming about flowcharts and business processes. After I had proposed this content I stumbled across a (printed and digital) document that is purportedly a GANT [sic] chart but is 100% text. More clues for the detecting process. Includes names of volunteers in the past who no longer are on board, I suspect. Hence my constant harping (okay, less constant harpy now) about "put it in the wiki not email" for the besotted hope that the wiki content will persist while emails (whether person specific or just the flash in the pan) won't.
Moral: Keep detecting.
Not an environmentally friendly way for me to do this, er, paper drawing but oh well, better to share my style than not. As I have no access to MS Visio, the tool I'd use in the past for process mapping, I went with the tool already widely used by the group, Open Office drawing. There's probably some way to move renderings between the platforms, not to mention the business processing modeling languages popular in that channel.
I'm searching for drawing templates (read: clipart) for people/teams, for folders, and even, gasp, 3-rin binders. Arrows and call-outs are looking good or will be. SAP Workflow gods and goddesses will recognize similarities in the notation, at a base level.
The primary objective I've taken on is identify where there is physical paper flow that could be automated/digitized. Before recommendations come study. Sponsors, or event locations, have specific detailed data, as illustrated by a classic handwritten form from a few decades back (at most).
I notice little things like the mailing address differing from the event location and wonder what would we ask for if this planning activity started today (probably ICS file comes to mind?)
GEO: 39.312026, -76.620418
LOCATION:The Restaurant at the End of the Universe
When I think about how these activities differ from business processes is these are primarily social with a necessary administrative side. Non-profits could be businesses from tax, finance or other angles. Maybe service delivery processes is more apt.
Back to the technical database level for a bit. The sponsors, as they're called, could be venues or vendors or clients, whatever. Keys functions are a communication research step where upcoming sessions are recorded. Of course, things change, so there's a periodic update/refresh phase. The document printed below is a recent generation.
In the 70's this would be called a "turnaround document". Sent out for data collection, returned to a central office for data entry. Probably still are.
Only fields from the organization table are shown, not prior history or current events. This is used to poll by phone (as far as I know now), which leads to questions on whether email, spreadsheet exchanges or maybe even a web presence (unlikely for this side to produce but not unlikely to consume). There's a confirmation step/process, as there should be. More on that in the future.
Another way, if I may digress a bit, of thinking about service organization flow takes me back to waste processing methodologies, essentially modelling natural decay or biological processes. I need to share the ideas as documents etc. alongside diagrams as simple as I can produce.
One critique from a predecessor in my role was the current published calendar text is 'free form' not lending itself to chronological sorting and other boring needs of life in the event trade.
Enter the VCAL file, or as rookie ABAP detectives call them, ICAL. The legacy data content has values such as:
Mon Jul 23
Aug 17-19Humans pick up what this means, hopefully without a second thought. Doesn't meet the VCALENDAR file expectations. Newer software might guess right, but for now, assume these will not compute.
So, new database table to match the old one per event/show detail. Can't easily extend the extant data structures since a calendar invite or series thereof, due to overload of the data cells. For example, the above one row showing August 17th through the 19th would be 3 calendar entries to that one line. I'll leave out the schema scheme parts.
My first take has minimal fields to get acceptable calendar invites, using Google and Apple devices. One of the Perl examples that got me bootstrapped is an advent calendar [ e.g. http://perladvent.org/2017/ and http://perladvent.org/2014/2014-12-18.html and of course http://perladvent.pm.org/2007/1/ ]. With minor headaches, I was able to connect these libraries to an ODBC driver (my old fave Perl DBD and DBI ) connected to a couple MS SQL databases. If you didn't follow that last sentence at all, bear with me.
select
DESCRIPTION,
DTSTART,
DURATION,
LOCATION,
concat(SUMMARY,\' : \',EventsCode)
from
event_calendar
where
EventsCode like \'H___\'
order by
StartDateTime
Looks odd because it's SQL inside a Perl program. Or not so odd I imagine.
The "H" search match is one of those letters noted in the first couple flow charts above as a data classification, albeit arbitrary if not capricious. This is merely a stub/proof of concept. The working versions would join more relevant and less redundant data.
Calendar files can have a single event, or multiple. This seems directly useful for plays, say, that run through an engagement, as opposed to another opening, [of] another show.
The invite dissemination plan is another future direction to be determined; while email attachments are the norm for many, and should kind of just work, making clickable links seems straightforward enough. I'm ignoring possibly critical infra chunks like serial IDs, timezones (which had interesting experimental case failures right quick).
A more polished example snippet:
<pre>
BEGIN:VCALENDAR
VERSION:2.0
PRODID:SBO2.0
BEGIN:VEVENT
DESCRIPTION:Cabaret
DTSTART:20181021T140000
DURATION:PT3H
LOCATION:806 S Broadway Baltimore MD 21231
SUMMARY:Vagabond Theatre
END:VEVENT
BEGIN:VEVENT
...
</pre>I chopped off the subsequent events, just to show the basic groups of data (header and detail in a sense).
Whether this work "goes to production" quickly or languishes time will tell (heh). Meanwhile I've learned some new wrinkles in connecting people to places where things happen, and made my life easier by knowing when I'm supposed to be somewhere.
Future:
Future 2:
Future 3:
Grateful thanks to susan.keohan for brainstorming about flowcharts and business processes. After I had proposed this content I stumbled across a (printed and digital) document that is purportedly a GANT [sic] chart but is 100% text. More clues for the detecting process. Includes names of volunteers in the past who no longer are on board, I suspect. Hence my constant harping (okay, less constant harpy now) about "put it in the wiki not email" for the besotted hope that the wiki content will persist while emails (whether person specific or just the flash in the pan) won't.
Moral: Keep detecting.
- SAP Managed Tags:
3 Comments
