Finally had time this weekend to re-jet the carburetor on my 2001 Sportster 1200 Custom (XL1200C). I’m now up to about a Stage .5, since all I’ve done is some minor carb work. I haven’t replaced the air cleaner with a high-flow unit or replaced the stock pipes yet. Turns out that I received the wrong intake gaskets, so I wasn’t able to replace them. I don’t know if I ordered the wrong ones or if they pulled the wrong ones. It doesn’t really matter at this point, since I was just going to replace them as a precautionary measure.

I love how straightforward and easy the Keihin carb is to work on. It reminds me of my days as an auto mechanic, back in the 80s; fuel injection was just beginning to take over on new cars and there were still as many carbureted cars coming into the shop as there were FI cars. I also like only having one carb for multiple cylinders, like a car, so that you don’t have to deal with carb syncing, etc. On my past import (Japanese) bikes, carb syncing was a pain in the @$$.

Anyway, the Dynajet kit went in with no issues. I stuck to the 160 main jet, that they recommend for stock setups. While I was in there, I also replaced the stock .42 pilot jet with a .45. I don’t know if it’s the dynajet kit or the pilot jet, but seat-of-the-pants testing would indicate a fair improvement in low-end driveability. Previously, it seemed kind of starved when trying to accelerate. Now, it just seems to have more “oomph” when I hit the throttle.

Hopefully, soon I’ll be able to spring for a higher flow A/C, and may re-route the crankcase ventilation while I’m at it. I’m not sure what to do with the exhaust at this point. I’m a fan of “rumble”, but not “loud and obnoxious”. We’ll see.

Share this:

UPDATED: I’ve changed employers and have moved on to other projects. I no longer use OTRS, or have access to OTRS, so I won’t really be able to help you beyond what I’ve already posted here.

Jeff

I’ve seen the number of people looking at my short entry dealing with importing items into OTRS’s CMDB, so I thought I’d expand on that a bit. I’ll go ahead and give a slight overview, then provide a quick-and-dirty description of how to manually import items into the CMDB. Later, when time permits, I’ll add a better explanation of how to automate the import process. I may clean this up at a later time, bur for now, I want to get down the basics.

You can manually import CMDB items (computers, software, etc.) into OTRS using the Import/Export function, via the web interface. There is also a way that you can automatically import items, via cron and the commandline. I have a brief overview of that here, but will create a more complete explanation at a later time. First things first though; you have to do the steps below anyway, before you can automatically import items. You have to have the import template created in order to automate the process, since the automation uses an existing template.

Overview

To create the template, we’ll need to identify what we’re importing, the delimiter, and the CMDB columns to be included. In my example, I’m importing desktop computers, the file is a comma-delimited format, and I’ll be submitting the minimum required fields.

Required Fields
What I mean by minimum required fields is that OTRS has a small number of fields within a CMDB record that have to be filled in. If you go into the CMDB section online and manually add an item, you can see what the requried fields are; they’ll be marked with an asterisk (star). For my desktop computer import, I’ll need to AT LEAST provide: Computer Name, Deployment State, Incident State, Network Adapter 1(NIC1), and whether it gets IP over DHCP.

Creating an Import Template

So, here’s a quick-and-dirty rundown of how to setup an import template. The values that are shown in the images below SHOULD get you a working template. You will however, probably want to edit the values to more precisely match what you need. As always, please read my disclaimer before proceeding.

Name: Name of your new templateObject: The object typeFormat: format of the import dataValid: set it as valid, if you want to be able to use the template…

4> When finished, click Next

5> Set the values in the Step 2 screen

Class: whatever type of import it will be – this affects what elements show up later.Maximum number of one element: Not sure what this does 🙂Empty field means keep value: This will leave existing data, rather than “blanking” it out.

6> When finished, click Next

7> Set the values in Step 3 screen

Column Separator: The separator used in your import file.Include Column Headers: That’s up to you. I do “No”

8> When finishd, click Next

9> Add mapping elements

There are a few things to note when adding elements:

1> Click “Add Mapping Element” to add a line for each field that is in the import file.
2> Add an entry for EVERY field in the import file, in the order they exist in the file.
3> There are some REQUIRED fields.These fields have to exist in the import file, and have valid values, in order for the record to import. The required fields are: Name,Deployment State, Incident State,NIC1,IP over DHCP Name,Vendor,Model,OS,NIC-IP

10> When finished adding elements, click Next

11> Fill in search criteria to be used for exporting (optional)

You don’t really need to do anything with this, if you’re only planning on importing items.

12> If/when you finish adding search criteria, click Finish

13> Note the number of the template that you just created

This should bring you back to Import/Export Management page that shows a listing of the existing Import/Export templates. You should see your newly created template listed there. Note the Number of your template, since this is what will be used to automate the import.

To actually import items, you’ll simply click on the “Import” link for the appropriate import template, select the source file with all of the records in it, and hit the “Import” button. When it finishes, it will give you Summary page which indicates total records, successes, and failures.

Share this:

The Sporty doesn’t seem to be getting enough gas to idle, if I push the choke all the way in, even after it’s warmed up. That would lead me to believe that it’s probably running lean on idle. When I went to reset the idle, I found out that the little anti-tamper plug had already been removed by someone. That makes things easier for me. The interesting thing is there are only 10k miles on the thing, with 8k of those coming from my brother-in-law and he claims no one has done any carb/tuneup work on the bike since he’s had it. He said the the previous guy bought a jet kit, but chickened out and didn’t put it in. I’m guessing that he probably went so far as to drill out the plug, but not do the jets. I still have the jet kit, plus I ordered a .45 pilot jet from J&P Cycles, so if/when I install those, I’ll see if everything is still stock on the inside.

I also ordered new intake and carb gaskets from J&P Cycles, since I’ve seen on the forums that those are only good for a few riding seasons before they dry up. If they’re dried up, they could be leaking and leaning things out some. I guess we’ll see once I get the parts and pull things apart.

Jeff Eske

Share this:

I got a “new” motorcycle over the weekend. It’s a used 2001 Harley-Davidson XL1200C Sportster. I wasn’t really in the market for a motorcycle, but the deal was too good to pass up. My brother-in-law was interested in selling it, and he gave me a good deal on it. It’s low miles (10k) and basically stock.

I’ve owned a few motorcycles over the years, but they’ve always been “vintage” japanese machines. The Sporty is the closest I’ve come to a new bike. All of the others basically required some resuscitation in order to be ride-able. I previously owned a 60s Suzuki 250cc two-cycle Scrambler, a ’76 Kawasaki KZ900 (the original superbike!), a 70s Suzuki 750 ( a top-heavy pig), and an ’87 Yamaha Virago 1100.

The Sporty is taking a while to get used to. Like the Suzuki 750, it seems like it’s slightly top-heavy. In addition to that, it has a somewhat stretched fork so, when turning, the frontend wants to “fall” in the direction you’re turning. Basically, when you start to turn, the handlebars really want to turn all the way in that direction. I rode my other brother-in-law’s Heritage Softtail and, even though it’s a lot heavier bike, it doesn’t feel as top-heavy and the steering feels “lighter”. These things aren’t deal-breakers, they’re just differences that I’ve noticed between the Sportster and the other bikes that I’ve ridden.

Share this:

It appears that, according to National Geographics “Doomsday Preppers” infographic (see the graphic and a link to the site below), my leatherworking hobby would put me in the top 10 Most Valuable Professions. You have to look pretty hard to find it (HINT: As far down and to the right as you can go).

Unlike some web services, the OTRS web services don’t return the values in specific xml tags; it uses generic “s-gensym” tags. Also, it returns field name within a set of generic tags, followed by the field value in a set of generic tags. Here’s part of the SOAP response:

In this example, you can see that the ServiceDown field(fusion:ServiceDown) has a value(fusion:v) of “false”. With OTRS, every time you run your SOAP request, you some random-ass “s-gensym” field name for everything.

To actually pull the SOAP response data out, you can use a foreach() loop and dump the field names and values into a more useful array. In addition to that, the array will be setup as a key/value pair, so you can actually get the field value by referring to the field name. I’m sure that there’s a much better, more elegant method to do the same thing, but this way works. First the code, then an explanation of what’s going on:

Basically, what this code does is take your SOAP response array ($ticketInfo) and run it through a foreach() loop. The OTRS SOAP response includes to entries for each field. The first entry is the field name and the second entry is the field value. So, what I want to do is combine both entries into a key->value pair in an array.

The foreach() explodes the values of the s-gensym variables out and adds the value to 2 different arrays. This is where the elegance is definitely lacking. I’m first saving the value into the $temp[] array to refer back to it later. Then, if the row is divisble by two – basically every other, or every second row, I grab the previous value from temp[] and write it to $ticketInfo[] as the key and write the current value as the value. What I end up with in the end is an array ($ticketInfo[]) that has the field name as the key and the field value as the value.

You can then pull the desired value by referring to the appropriate key, such as:

$ticket_age = $ticketInfo[Age];
$ticket_title = $ticketInfo[Title];

A simple way to print out all of the values in your array is, again, with the foreach() loop. All you need is this little piece of code:

What I’d like to do here is just note some observations that I’ve made while messing around trying to figure all of this out. Hopefully it will be of some use to someone. As with everything on this site, the Disclaimer holds here to – all I can guarantee is that this stuff worked for me. What I have listed below is what I’ve determined from trial-and-error, so take it with a grain of salt. This is almost more to document it for myself than anyone else.

===============

TicketCreate() –
Purpose: Used to create new tickets object (duh!). Generally, you’ll want to do an ArticleCreate() also, to add some useful information to the ticket.Required Input Values: TypeID(integer), QueueID(integer), LockID(integer), PriorityID(integer), State(text), CustomerUser(text), OwnerID(integer), UserID(integer).Optional, but Recommended: Title(text). The title is required, but it seems logical to add one.Returns: TicketID(integer)

Basically, all that’s required is passing one argument, the TicketID, and you can get back ALL of the ticket details. It’s actually much more straightforward than I assumed that it would be. One thing that I noticed is that reading through the OTRS dev documentation, the order that the ticket details are returned is different than what actually comes back. That’s not really a big deal, since I moved everything into an array, with the various ticket details saved as a key/value pair. More on that later. The example that I have here only returns the ticket, but it is possible to return the associated articles also, but that will be for a later post.

All I’m passing in is the SOAP username and password, along with the TicketID. What it returns then is an XML-formatted response. My page parses all of the returned values into an array, by using a foreach loop. There are probably much more elegant solutions, but this works. Because of the way OTRS returns things, my foreach loop is a little janky. Like I said, there’s probably a more elegant solution.

As I said – a little janky. Anyway, basically what OTRS does it returns the detail’s name as a variable, then the detail’s value as the NEXT variable like: “Age”, “123421”, “Title”, “This is my ticket title”, “TicketID”, “2”, so basically, you get the detail name, then the detail value. To get these into a usable format, I’m basically creating 2 arrays, $temp[] and $ticketinfo[]. Since I’m simple-minded, the easiest thing for me to do was to create the $temp[] array so that I could basically use it as the “key” array when populating the $ticketinfo[] array. Then what I’m doing is basically putting things into the $ticketinfo[] array as key/value pairs. I take the current value – $value and put it in as the value and use the previously returned value, from $temp[], as the key.

I’ve included the complete commented code for the page below. You can copy/paste it into a new, blank page, or you can download the zipped version of the file below.

############################################################################ You don't have to change anything below here, although you can ############################################################################

#### Get the SOAP response into an array as key/value pairs ##### This is kind of janky, but what it does is parse out the ## detail values in the SOAP response and writes them as a key/value ## pair in the $ticketInfo[] array. #

################################################################################## The code below here is just to provide viewable proof that it worked ######## It can all be commented out or removed ###################################################################################### Return the SOAP request and response as xml-formatted text ####print "<pre>\n"; print "Request :\n".htmlspecialchars($client->__getLastRequest()) ."\n"; print "Response:\n".htmlspecialchars($client->__getLastResponse())."\n"; print "</pre>";

Share this:

Some time back, while working out web services on another project, I put together a janky little snippet of PHP code that’s actually pretty handy when dealing with SOAP-based web services. For me, the hardest part of working with web services is trying to figure out exactly what the request needs to look like to work correctly. The other thing is figuring out exactly what I got back! This little snippet actually shows you what the xml-formatted SOAP request and SOAP response each look like. The REALLY nice thing is that it only takes 4 lines of code.

Basically, all you do is plug this in after you’ve created your new SoapClient() object and performed the soapCall(). A basic example would look like the code below. Please note, this isn’t a working piece of code, just an illustration of how it would look.

What this should get you, when you run the script, is two separate, preformatted lines of text. The first line will be the XML-formatted request that PHP sent to the web service. The second line should be the XML-formatted response returned. Granted, this doesn’t necessarily give you the final format that you need, but it will get you names of all of the XML variables that have been returned. With that information, you can proceed to find a way to extract the information that you need.