One of our projects is to create/change hundreds of maps and switch from SAP IDoc flat files to XML files. All of the test files are in the FlatFile format, so I decided to create a converter to translate them into XML. It’s clear that this task requires some kind of a library with the IDoc documents structures description (hierarchy, records, positions, etc). I decided to use IDoc DDFs (format used by IBM/Sterling Map Editor for creating structures – you can download them from GIS/SI or just use existing GIS/SI map) and XSLT for it, and several hours later can convert my test data from FF to XML in seconds:
Just an idea.
PS I don’t have access to SAP at the moment so I cannot use it for XML Idoc generation. Also, I have appropriate I/Os for existing IDocs so it made sense to convert these existing files.
PPS it’s clear that an XML->FF converter is easier to develop – you don’t need to care about the hierarchy.
Here is my XSLT code. It doesn’t work without appropriate DDF file so if you have no idea about XSL/DDF you won’t be able to use it. It’s for those who is experienced but lazy – just like me 🙂 Continue reading
Working with our client’s SI 5.2.4 I saw that some BPs store data for 10 years in the database, in spite of the LifeSpan of 15 days. I tried to find all the BPs with this strange behavior:
select * from WFD where WFD_ID in
(select WFD_ID from WF_INST_S where WORKFLOW_ID in
(select WF_ID from ARCHIVE_INFO where
CONVERT(varchar(10), archive_date, 11) like '24/%')
group by WFD_ID, WFD_VERSION)
And found, that all these BPs call for Mailbox. On the IBM Support portal I found the reason of it: FAQ: Who is responsible for deleting the files on file system if BP storage is set to file system:
– mailbox actions will lead to a life span of 10 years, so that a download is possible.
A post about the Backup Service – again. If your GIS/SI saves archive data on disk and you do not clean it up from time to time, one day you might run out of space on this disc, Backup Service will stop working (“Error running backup”) and you might get a bunch of problems I described before. To prevent it you should control the archive folders and delete them from time to time.
First of all, you should know where these folders are located. Go to Operations > Archive Manager > Configure Archive Settings in the Dashboard and check Backup Directory setting:
If you open this directory, you’ll see a lot of subdirectories with the names in YYYYMMDD format, or something like this. You actually don’t need them all, especially the old ones (I would say the ones which are 2+ months old). So, you can move them to another disk and then delete the old directories. Or, you can simply delete all the old directories – you don’t need them in 99.99% cases. Some people think that they could use these backups for a Disaster Recovery, but it’s not true – they contain detailed information mostly from CORRELATION_SET, WORKFLOW_CONTEXT and so on. So, usually 2 months later you don’t need them (I hope your BPs save all the I/O documents separately?)
So, if you’re running out of space, you should delete the old directories and create some kind of a scheduled job which will be deleting old directories from time to time – to keep the system nice and clean.
I’ve worked with the specs in different formats – MS Word, MS Excel, PDF, TXT, scanned images and so on. For PDF specs I use Foxit Reader – I love it (and I don’t like Adobe Acrobat). I it allows me to make comments, draw primitive figures and so on.
Often the specs contain a lot of unnecessary information – list of authors, notes, history of changes, “how to read this spec” section and other junk which bothers you and distracts from your work – I hate scrolling all of these pages to the right one 🙂 If the spec in MS Word or TXT format, you can simply delete these blah-blah pages. But you are not so flexible with PDF. I use this: I simply “print” essential pages with my PDF printer (one comes with the Foxit Reader):