I know this is meant to be a basic interface with so complexity, but let's be realistic about the requirements we are likely to get. Even a simple upsert of something as basic as a service request is likely to require a bit of digging into bookshelf so that the interface is able to mimic basic GUI functionality. I will discuss some of the most commonly used User Properties necessary to implement even an advanced interface. When in doubt about the syntax of any of these properties, take a look for an example in the Tools flat view.
PICKLIST
This is the most common Integration Component Field User Property you will see and it basically tells the EAI Siebel Adapter to validate the picklist in the interface. This property is generally created by the wizard so I bring it up only because validating the picklist here will allow for several different ways to interpret a picklist field value described by some of the user properties below.
PicklistUserKeys
In the GUI, when you type an account name in the Account field on another BC that has a picklist of Accounts, and there is more than one record matching that name (with different locations), a pick applet will pop open with the constrained list of accounts having that name. The GUI is letting a user decide which of the multiple records returned was meant to be picked. An interface does not have that luxury, so the PicklistUserKeys Integration Component Field User Property is provided to mimic this action. The value of this property should be a comma separated list of fields representing the logical key of the picklist record to look up. These fields must all be present in the integration component (though there values can be null). The 'PICKLIST' user property must also exist for the field where this property is used and its value must be 'Y'.
Ignore Bounded PickList
When a picklist is validated in the interface and the value passed is not found, the EAI Siebel Adapter stops processing and returns an error. If the data is expected to sometimes be missing though, you may want the foreign key to just be left blank. For instance, maybe the service request, in our example is tied to an order via a back office order number, but the order was never loaded. Add this user property with a value of 'Y' in combination with the PICKLIST user property with a value of 'Y'. The EAI Siebel Adapter will look up the record by the user key provided (can also be used in combination with PickListUserKeys) but if it is not found, will set the field to blank in the integration object before applying the data. Keep in mind that this property will only work as expected if the Picklist object the underlying BC uses to constrain the field is set to No Insert equals True, otherwise, the EAI Siebel Adapter will try to insert a record. Also note that in bookshelf there is a typo in that there should be spaces between the words of the property name.
FieldDependency
It is easy in the GUI to determine the order of the fields being picked, either by training or by sequencing the fields in a particular way during applet design. This may help set the fields that will be used to constrain the value of another field, frequently in a hierarchical picklist. In EAI, we achieve this result through this user property. It can be used multiple times with a sequence number, just like other BC and applet user properties. The value is a field integration component field name. Siebel claims that pickmapped constraints are automatically taken into account, and that may typically be the case, but I have seen times when it does not work, so this is a good fall back.
Monday, November 15, 2010
Friday, October 29, 2010
A Basic Interface - Web Service Workflow
Just about every interface consists of two basic components: the integration object(s) and the workflow or business service. I will demonstrate a workflow approach which will give you more opportunity to customize down the road.
It is here that we begin to differentiate the integration by the communication mechanism. Because I am designating this integration as a Web Service, that will drive the type of data this workflow will expect as an input and output. The workflow I build will eventually be exposed as a WSDL to be consumed by an external program. That WSDL should have the definition of the message it is expecting, in this case, the XSD, or definition of the Integration Object we just built. How we accomplish this is to set the Input Process Property to a Data Type of 'Integration Object' and to actually specify the integration object we built, in the Integration Object attribute of the process property.
You can also see my place holder for the SR Number that I want to return to the external system in the response message. The 'IncomingXML' property is already in the format needed to be passed to the EAI Siebel Adapter, so there is no conversion necessary. And we are assuming that the data being passed is exactly as it should be applied. You will create the following steps which I will explain (other than Start and End which are self explanatory):
The 'Upsert SR' is a Business Service calling 'EAI Siebel Adapter'. Now here is the another design decision to be made. Each of the available methods differentiate exactly how the data should be applied. But there are two broad determinations. If we were to use the Execute method, then the 'operation' element which exists in each component of the IO would be used to determine how the data should be applied. This gives more control the calling system (or a data map which I will discuss later). The other set of methods essentially comprise a One Size Fit All to applying all the data uniformly. I will use the latter approach here and set the method to 'Upsert'. There is only one component in my IO, so if it exists, it will be updated, otherwise it will be inserted. The input arguments for this step are the IncomingXML message from the external system and a parameter telling the EAI Siebel Adapter to create the Status Object.
There is one Output Argument. We no longer care about the input message at this point because it will have been applied so we just overwrite it with the return, which in this case will be the status key.
The last step in the WF is another Business Service step calling 'PRM ANI Utility Service', 'GetProperty' method. This business service has a plethora of useful methods for manipulating property sets. This particular method will extract the value of a field from an integration object instance. Here are the inputs:
The output is to set the process property 'SRNumber' with the Output Argument, 'Property Value'. When the return message is sent back to the calling system, this property will exist with the generated SR Number.
Simulating/Troubleshooting this WF from within tools is difficult as built so I sometimes add a bypass step off the start branch to read the integration object from a file. I may talk about this later but want to keep this post pretty straightforward. So for now, this workflow can just be deployed, checked in and activated.
It is here that we begin to differentiate the integration by the communication mechanism. Because I am designating this integration as a Web Service, that will drive the type of data this workflow will expect as an input and output. The workflow I build will eventually be exposed as a WSDL to be consumed by an external program. That WSDL should have the definition of the message it is expecting, in this case, the XSD, or definition of the Integration Object we just built. How we accomplish this is to set the Input Process Property to a Data Type of 'Integration Object' and to actually specify the integration object we built, in the Integration Object attribute of the process property.
You can also see my place holder for the SR Number that I want to return to the external system in the response message. The 'IncomingXML' property is already in the format needed to be passed to the EAI Siebel Adapter, so there is no conversion necessary. And we are assuming that the data being passed is exactly as it should be applied. You will create the following steps which I will explain (other than Start and End which are self explanatory):
The 'Upsert SR' is a Business Service calling 'EAI Siebel Adapter'. Now here is the another design decision to be made. Each of the available methods differentiate exactly how the data should be applied. But there are two broad determinations. If we were to use the Execute method, then the 'operation' element which exists in each component of the IO would be used to determine how the data should be applied. This gives more control the calling system (or a data map which I will discuss later). The other set of methods essentially comprise a One Size Fit All to applying all the data uniformly. I will use the latter approach here and set the method to 'Upsert'. There is only one component in my IO, so if it exists, it will be updated, otherwise it will be inserted. The input arguments for this step are the IncomingXML message from the external system and a parameter telling the EAI Siebel Adapter to create the Status Object.
There is one Output Argument. We no longer care about the input message at this point because it will have been applied so we just overwrite it with the return, which in this case will be the status key.
The last step in the WF is another Business Service step calling 'PRM ANI Utility Service', 'GetProperty' method. This business service has a plethora of useful methods for manipulating property sets. This particular method will extract the value of a field from an integration object instance. Here are the inputs:
The output is to set the process property 'SRNumber' with the Output Argument, 'Property Value'. When the return message is sent back to the calling system, this property will exist with the generated SR Number.Simulating/Troubleshooting this WF from within tools is difficult as built so I sometimes add a bypass step off the start branch to read the integration object from a file. I may talk about this later but want to keep this post pretty straightforward. So for now, this workflow can just be deployed, checked in and activated.
A Basic Interface - Building the Integration Object
I am not sure how easy it will be to summarize EAI in a couple of blog posts as there are definately a lot of ifs and buts in the design process. Nevertheless, I think it wold be useful to show how to build a basic interface using a couple of different techniques. Frequently you client's enterprise architecture will drive which to use.
Integration generally takes one of three forms
Regardless of approach, the basic component of most interfaces is the structure of how data is viewed or applied. Let's say we need to Upsert a Service Request. A Schema Update assumes a hierarchical organization of data using the Integration Object data structure. Bookshelf provides extensive instruction on how these are built and configured to achieve certain goals so I will only touch on the highlights.
First, create an Integration Object in Siebel: from the Tools File Menu, New Object Wizard, EAI Tab, choose Integration Object. In the wizard, select the Project and choose 'EAI Siebel Wizard' from the second dropdown, and click Next. For the purpose of this example, we can just use the Service Request business object as the source object and the root BC will be Service Request. Enter a name of your choosing and click Next. In the next wizard page, deselect all child objects for which there are no fields to set. In this case that will be all of them except for the root as the more objects and fields in the message, the longer it will take the various architecture components to parse and translate the message. Click Next, then Finish on the next page.
Your Integration Object has been created. The next step is to verify the user keys. An integration object needs to have a valid user key in order to do an upsert. This basically specifies which key fields to use to find a record to update. In my example for Service Request, a key was not generated by the wizard so I will create one. Navigate to Integration Component Key in the explorer under the Service Request Integration Component. Create a new record, provide a name, set the sequence number to 1 and the key type to 'User key'. Create a child record in Integration Component Key Fields, provide a name and set the Field Name to 'Id'.
Another optional step we will use in this example is the Status Key. After creating a service request, I want to return the service request number to the external system as verification of success and so this SR can be referenced later by the customer. To do this we use the Status Key. This is basically a structure of the data set we wish to return from the EAI Siebel Adapter call and pass back to the calling system. A Status Key can be specified for each Integration Component so the final data set is the structure of all the keys combined hierarchically. In this case, navigate to Integration Component Key in the explorer under the Service Request Integration Component, create another new record, provide a name, 'StatusKey, set the sequence number to 1 and the key type to 'Status key'. Create a child record in Integration Component Key Fields, provide a name and set the Field Name to 'SR Number'.
Finally, while not absolutely necessary, you should inactivate all fields you are not using for each Integration Component. For an inbound upsert to Siebel, the calling system does not need to provide all the fields that are active in the IO schema, but if the field is active in the IO, then the external system Could send that data element which may have undesired affects depending on the interface. Make sure all fields used in the key are activated as well as all fields being passed from the external system. Unlike BC field lengths, the length property of an Integration Component Field is more important as when an XSD is generated and provided to the external system, this property will frequently be used by the web development tool to validate the data entered into that field. You can also change the XML Tag attribute to a label recognized by the external system (so long as spaces are removed).
One thing to keep in mind is that if an insert is desired, then the calling system should just pass a constant to the user key field, 'Id' so that Siebel will not find a record and a new one will be created. A value like '_New_Record_' is a safe value because the '_' will never be part of a generated row id.
Integration generally takes one of three forms
- Query - Returns a data set of source data to be displayed in the target system
- Schema Update - Takes a hierarchical data structure and applies it to the target system
- Functional Action - Triggers a service to perform some set of business rules
Regardless of approach, the basic component of most interfaces is the structure of how data is viewed or applied. Let's say we need to Upsert a Service Request. A Schema Update assumes a hierarchical organization of data using the Integration Object data structure. Bookshelf provides extensive instruction on how these are built and configured to achieve certain goals so I will only touch on the highlights.
First, create an Integration Object in Siebel: from the Tools File Menu, New Object Wizard, EAI Tab, choose Integration Object. In the wizard, select the Project and choose 'EAI Siebel Wizard' from the second dropdown, and click Next. For the purpose of this example, we can just use the Service Request business object as the source object and the root BC will be Service Request. Enter a name of your choosing and click Next. In the next wizard page, deselect all child objects for which there are no fields to set. In this case that will be all of them except for the root as the more objects and fields in the message, the longer it will take the various architecture components to parse and translate the message. Click Next, then Finish on the next page.
Your Integration Object has been created. The next step is to verify the user keys. An integration object needs to have a valid user key in order to do an upsert. This basically specifies which key fields to use to find a record to update. In my example for Service Request, a key was not generated by the wizard so I will create one. Navigate to Integration Component Key in the explorer under the Service Request Integration Component. Create a new record, provide a name, set the sequence number to 1 and the key type to 'User key'. Create a child record in Integration Component Key Fields, provide a name and set the Field Name to 'Id'.
Another optional step we will use in this example is the Status Key. After creating a service request, I want to return the service request number to the external system as verification of success and so this SR can be referenced later by the customer. To do this we use the Status Key. This is basically a structure of the data set we wish to return from the EAI Siebel Adapter call and pass back to the calling system. A Status Key can be specified for each Integration Component so the final data set is the structure of all the keys combined hierarchically. In this case, navigate to Integration Component Key in the explorer under the Service Request Integration Component, create another new record, provide a name, 'StatusKey, set the sequence number to 1 and the key type to 'Status key'. Create a child record in Integration Component Key Fields, provide a name and set the Field Name to 'SR Number'.
Finally, while not absolutely necessary, you should inactivate all fields you are not using for each Integration Component. For an inbound upsert to Siebel, the calling system does not need to provide all the fields that are active in the IO schema, but if the field is active in the IO, then the external system Could send that data element which may have undesired affects depending on the interface. Make sure all fields used in the key are activated as well as all fields being passed from the external system. Unlike BC field lengths, the length property of an Integration Component Field is more important as when an XSD is generated and provided to the external system, this property will frequently be used by the web development tool to validate the data entered into that field. You can also change the XML Tag attribute to a label recognized by the external system (so long as spaces are removed).
One thing to keep in mind is that if an insert is desired, then the calling system should just pass a constant to the user key field, 'Id' so that Siebel will not find a record and a new one will be created. A value like '_New_Record_' is a safe value because the '_' will never be part of a generated row id.
Tuesday, August 17, 2010
Common (or not) eScript Syntax Errors
I would love to post a comprehensive list of gotchas, but then that would make them not gotchas if you know what I mean as I would know them all. So instead, I will mention what sidelined me for several hours last night and hope to spur some discussion about what other people have come across. If I think of others over time, I will try to update this post.
Space after the function name. I had copied and pasted some functions from somewhere else in my client's repository and the functions had no space between the name and the opening parenthesis of the passed variable declarations. I was not (and I guess still am not) aware of a limitation in this regard, but I saw all sorts of strange behavior afterward. Namely, the calls to these functions seemed to be ignored which took me a long time to realize. They seem to work fine in their original home elsewhere in the repository so this may be related to context, but suffice to say this is some thing to think about when troubleshooting.
Space after the function name. I had copied and pasted some functions from somewhere else in my client's repository and the functions had no space between the name and the opening parenthesis of the passed variable declarations. I was not (and I guess still am not) aware of a limitation in this regard, but I saw all sorts of strange behavior afterward. Namely, the calls to these functions seemed to be ignored which took me a long time to realize. They seem to work fine in their original home elsewhere in the repository so this may be related to context, but suffice to say this is some thing to think about when troubleshooting.
Friday, July 23, 2010
My Barcode Promised Land
The effort of trial and error, traversing dead ends, and determining what I could not do, led me eventually to what I could. Let me start by saying that if I was a Siebel engineer (completely unaware of what constraints they had to work with) I would have provided an Application level method called something like BarcodeScan that could be trapped. I could then put a runtime event on it and trigger a wokflow when I was done. But then again I also would not have coded in the limitations I mentioned earlier.
Barring all that, I still needed a couple of basic things:
Let me start by walking through the most important Must-Have
Hook to trigger additional functional logic
I have sort of hinted at how this was achieved in general. Once I realized that the 'HTML FS Barcoding Tool Bar' was getting called, I modified the server script on this service to log when its methods are called. The important method here is 'ProcessData' which is the one method called regardless of the processing mode in use. At this point you have the barcode data and the Entry mode. You can also determine what view you are on via ActiveViewName. I trapped the Find, New and Update methods in the PreInvokeMethod event to store the current processing mode in profile attribute:
boBCMappings = TheApp.GetBusObject("FS Barcode Mappings");
bcBCMappings = boBCMappings.GetBusComp("FS Barcode Mappings");
Barring all that, I still needed a couple of basic things:
- Hook to trigger additional functional logic
- Do lookups on Serial Numbers
- Minimize the number of clicks
- Do lookups on the child record of a BC
- Parse the input so that I could do different stuff based on the type of data
Let me start by walking through the most important Must-Have
Hook to trigger additional functional logic
I have sort of hinted at how this was achieved in general. Once I realized that the 'HTML FS Barcoding Tool Bar' was getting called, I modified the server script on this service to log when its methods are called. The important method here is 'ProcessData' which is the one method called regardless of the processing mode in use. At this point you have the barcode data and the Entry mode. You can also determine what view you are on via ActiveViewName. I trapped the Find, New and Update methods in the PreInvokeMethod event to store the current processing mode in profile attribute:
switch (MethodName) {
case "Find":
case "New":
case "Update":
TheApp.SetProfileAttr("BarcodeProcessMode", MethodName);
break;
}With these three fields, the View, Process Mode, and Entry Mode, I can query the FS Barcode Mappings BC for a unique record.boBCMappings = TheApp.GetBusObject("FS Barcode Mappings");
bcBCMappings = boBCMappings.GetBusComp("FS Barcode Mappings");
with (bcBCMappings) {
ClearToQuery();
SetViewMode(AllView);
ActivateField("Field");
ActivateField("Applet BC");
SetSearchSpec("View", sView);
SetSearchSpec("Entry Mode", sEntryMode);
SetSearchSpec("Process Mode", sProcessMode);
ExecuteQuery(ForwardOnly);
bFound = FirstRecord();
if (bFound) {
...What I want to get from that record for now is the lookup field. I also need to know the Active BC to do the lookup in. Again, I cannot use ActiveBusComp or ActiveApplet so I just added a join to the FS Barcode Mappings BC to the repository S_APPLET table based on the applet name already stored in the Admin BC and added a joined field based on S_APPLET.BUSCOMP_NAME. I still feel like there is a better way to do it, but that is where I am at right now. Anyway, from the admin record I have a BC to instantiate, a field to set a search spec on, and the text value of the search spec.sField = GetFieldValue("Field");
sBusComp = GetFieldValue("Applet BC");
boObject = TheApp.ActiveBusObject();
bcObject = boObject.GetBusComp(sBusComp);
with (bcObject) {
ClearToQuery();
SetViewMode(AllView);
ActivateField(sField);
SetSearchSpec(sField, sLogicalKey);
ExecuteQuery(ForwardOnly);
bFound = FirstRecord();
if (bFound) {
...My client has multiple barcode processes so all this could be happening in different places. So the last step is to add some logic to branch out my hook. I am using the BC for now but we could make this more robust:switch (sBusComp) {
case "Service Request":
ProcessSR();
break;
case "Asset Mgmt - Asset":
ProcessAsset();
break;
}
The Dead Ends of Barcode Hacking
Most technical blog posts are about solutions. Since this series on Barcodes is also about my journey, I thought it might be interesting to also talk about what I tried out but did not work. Who knows, maybe I can save someone the effort of trying these. Or perhaps the patterns I am finding through these dead ends will help someone head off into a totally new direction as it has helped me.
Auto Enabling
So the first thing I though would be cool would be to auto enable the Barcode tool bar and the natural place to do this seemed to be on the Application Start event. After a lot of trial and error, my application kept crashing after trying to invoke the 'Active' method. The 'Active' method receives as an input the Active View Name and Active Applet Name. The startup page is not actually instantiated yet when the Application Start event executes so even hard coding a startup page into the input property set results in an application crash. So Application Start is not the right place.
Applet Context
When trying to call various barcode service methods through script, many of them require the applet name as an input parameter. Trying to use ActiveApplet though results in an error you would typically receive when you are not in a GUI context, such as when using EAI. ActiveViewName does work though so it is only the applet. I think what is happening is that clicking on a toolbar button, even though an applet appears to remain in focus (via the color pattern of the applets) focus is actually on the toolbar and hence active applet does not work. Well that is my theory anyway.
Default to Find Mode
My client will mainly be using the Find process mode so I thought it would be good that if I could not Auto Enable the tool bar, at least I could auto default the toolbar to Find mode once it is enabled. So I trapped the Active method on the business service and called the Find method from the InvokeMethod event after the Active method runs. But this does not quite work. If I click the Enable button twice though it does. It appears that this is a context issue. It is as if GUI context has been returned to the user prior to the Find script executing.
I noticed that a series of barcode events trigger anyway when the Application starts. I therefore tried triggering my auto enable scripts from the tail end of one of these events, again through the InvokeMethod event, but again ran into the context issue.
SWE From Script
The interesting thing to me is that the input parameters to all of these methods are a series of SWE Commands, Methods and parameters. It seems as though another browser thread or frame is being used where SWE commands are the language Siebel uses to initiate the logic. There is probably a way to call a SWE command directly through script but I am not aware of it. What I am thinking is to use SWE command to refresh the context of the GUI thread after a Barcode method has been called, then to explicitly call a followup method. I cannot do this directly as the results of the second method call appear to get lost as the context has been returned to the GUI before the second call.
Auto Enabling
So the first thing I though would be cool would be to auto enable the Barcode tool bar and the natural place to do this seemed to be on the Application Start event. After a lot of trial and error, my application kept crashing after trying to invoke the 'Active' method. The 'Active' method receives as an input the Active View Name and Active Applet Name. The startup page is not actually instantiated yet when the Application Start event executes so even hard coding a startup page into the input property set results in an application crash. So Application Start is not the right place.
Applet Context
When trying to call various barcode service methods through script, many of them require the applet name as an input parameter. Trying to use ActiveApplet though results in an error you would typically receive when you are not in a GUI context, such as when using EAI. ActiveViewName does work though so it is only the applet. I think what is happening is that clicking on a toolbar button, even though an applet appears to remain in focus (via the color pattern of the applets) focus is actually on the toolbar and hence active applet does not work. Well that is my theory anyway.
Default to Find Mode
My client will mainly be using the Find process mode so I thought it would be good that if I could not Auto Enable the tool bar, at least I could auto default the toolbar to Find mode once it is enabled. So I trapped the Active method on the business service and called the Find method from the InvokeMethod event after the Active method runs. But this does not quite work. If I click the Enable button twice though it does. It appears that this is a context issue. It is as if GUI context has been returned to the user prior to the Find script executing.
I noticed that a series of barcode events trigger anyway when the Application starts. I therefore tried triggering my auto enable scripts from the tail end of one of these events, again through the InvokeMethod event, but again ran into the context issue.
SWE From Script
The interesting thing to me is that the input parameters to all of these methods are a series of SWE Commands, Methods and parameters. It seems as though another browser thread or frame is being used where SWE commands are the language Siebel uses to initiate the logic. There is probably a way to call a SWE command directly through script but I am not aware of it. What I am thinking is to use SWE command to refresh the context of the GUI thread after a Barcode method has been called, then to explicitly call a followup method. I cannot do this directly as the results of the second method call appear to get lost as the context has been returned to the GUI before the second call.
Thursday, July 22, 2010
Hacking the 'HTML FS Barcoding Tool Bar' Business Service
In case you were curious what happens in the black box, once the Barcode toolbar is up and running, here is a dump of the Input and Output property sets from each Method that is called:
When the application starts up, the 'IsBarcodeEnabled' method is called about 15 times, is passed an empty property set and returns:
Also on startup, the 'ResetButton' method is called which appears to set the set which buttons on the toolbar are turned on or off and which buttons are active. Resetting them makes the enable button Active and off, and the process mode buttons inactive and off, as you can see from the outputs. Here are the Inputs:
And these Outputs:
The control keys are then determined. First the 'GetStartKeyCode' method is called with these Inputs:
And these Outputs:
Lastly, the End key via the 'GetEndKeyCode' method with these Inputs:
And these Outputs:
Clicking the enable button triggers the 'Active' method has these Inputs:
and these Outputs:
Clicking the Find button gives you these Inputs:
And these Outputs:
Clicking the New button (on the toolbar) gives you these Inputs:
And these Outputs:
Clicking the Update button (on the toolbar) gives you these Inputs:
And these Outputs:
And perhaps the most important one, scanning the data. This executes the 'ProcessData' method and would occur after the second end control character is received from the scanner. The Inputs are:
And these Outputs:
Keep in mind that in many cases, the actual property values are based on data pulled from the 'FS Barcode Mappings' BC.
When the application starts up, the 'IsBarcodeEnabled' method is called about 15 times, is passed an empty property set and returns:
01 Prop 01: IsBarcodeEnabled / 1
Also on startup, the 'ResetButton' method is called which appears to set the set which buttons on the toolbar are turned on or off and which buttons are active. Resetting them makes the enable button Active and off, and the process mode buttons inactive and off, as you can see from the outputs. Here are the Inputs:
01 Prop 01: SWECmd / InvokeMethod
01 Prop 02: SWEMethod / ResetButton
01 Prop 03: SWEService / HTML FS Barcoding Tool Bar
01 Prop 04: SWERPC / 1
01 Prop 05: SWEC / 1
01 Prop 06: SWEIPS / @0*0*0*0*0*3*0*
And these Outputs:
01 Prop 01: NEW_ENABLED / N
01 Prop 02: ACTIVE_ENABLED / Y
01 Prop 03: ACTIVE_CHECKED / N
01 Prop 04: UPDATE_CHECKED / N
01 Prop 05: FIND_ENABLED / N
01 Prop 06: FIND_CHECKED / N
01 Prop 07: NEW_CHECKED / N
01 Prop 08: UPDATE_ENABLED / N
The control keys are then determined. First the 'GetStartKeyCode' method is called with these Inputs:
01 Prop 01: SWECmd / InvokeMethod
01 Prop 02: SWEMethod / GetStartKeyCode
01 Prop 03: SWEService / HTML FS Barcoding Tool Bar
01 Prop 04: SWERPC / 1
01 Prop 05: SWEC / 2
01 Prop 06: SWEIPS / @0*0*0*0*0*3*0*
And these Outputs:
01 Prop 01: KeyCode / 220
Lastly, the End key via the 'GetEndKeyCode' method with these Inputs:
01 Prop 01: SWECmd / InvokeMethod
01 Prop 02: SWEMethod / GetEndKeyCode
01 Prop 03: SWEService / HTML FS Barcoding Tool Bar
01 Prop 04: SWERPC / 1
01 Prop 05: SWEC / 3
01 Prop 06: SWEIPS / @0*0*0*0*0*3*0*
And these Outputs:
01 Prop 01: KeyCode / 220
Clicking the enable button triggers the 'Active' method has these Inputs:
01 Prop 01: SWEActiveView / All Service Request List View
01 Prop 02: SWECmd / InvokeMethod
01 Prop 03: SWEMethod / Active
01 Prop 04: SWEActiveApplet / Service Request List Applet
01 Prop 05: SWEService / HTML FS Barcoding Tool Bar
01 Prop 06: SWERPC / 1
01 Prop 07: SWEC / 22
01 Prop 08: SWEIPS / @0*0*0*0*0*3*0*
and these Outputs:
01 Prop 01: OPTION0 / Service Request
01 Prop 02: NEW_ENABLED / Y
01 Prop 03: OPTION2 / Repair
01 Prop 04: ACTIVE_ENABLED / Y
01 Prop 05: ACTIVE_CHECKED / Y
01 Prop 06: OPTION3 / Pick Ticket
01 Prop 07: UPDATE_CHECKED / N
01 Prop 08: OPTION6 / Serial #
01 Prop 09: FIND_ENABLED / Y
01 Prop 10: Check / 1
01 Prop 11: OPTIONS_LENGTH / 7
01 Prop 12: OPTION4 / Order
01 Prop 13: FIND_CHECKED / Y
01 Prop 14: OPTION5 / Product
01 Prop 15: NEW_CHECKED / N
01 Prop 16: OPTION1 / Asset #
01 Prop 17: UPDATE_ENABLED / Y
Clicking the Find button gives you these Inputs:
01 Prop 01: SWEActiveView / All Service Request List View
01 Prop 02: SWECmd / InvokeMethod
01 Prop 03: SWEMethod / Find
01 Prop 04: SWEActiveApplet / Service Request List Applet
01 Prop 05: SWEService / HTML FS Barcoding Tool Bar
01 Prop 06: SWERPC / 1
01 Prop 07: SWEC / 11
01 Prop 08: SWEIPS / @0*0*0*0*0*3*0*
And these Outputs:
01 Prop 01: OPTION0 / Service Request
01 Prop 02: NEW_ENABLED / Y
01 Prop 03: OPTION2 / Repair
01 Prop 04: ACTIVE_ENABLED / Y
01 Prop 05: ACTIVE_CHECKED / Y
01 Prop 06: OPTION3 / Pick Ticket
01 Prop 07: UPDATE_CHECKED / N
01 Prop 08: OPTION6 / Serial #
01 Prop 09: FIND_ENABLED / Y
01 Prop 10: Check / 1
01 Prop 11: OPTIONS_LENGTH / 7
01 Prop 12: OPTION4 / Order
01 Prop 13: FIND_CHECKED / Y
01 Prop 14: OPTION5 / Product
01 Prop 15: NEW_CHECKED / N
01 Prop 16: OPTION1 / Asset #
01 Prop 17: UPDATE_ENABLED / Y
Clicking the New button (on the toolbar) gives you these Inputs:
01 Prop 01: SWEActiveView / All Service Request List View
01 Prop 02: SWECmd / InvokeMethod
01 Prop 03: SWEMethod / New
01 Prop 04: SWEActiveApplet / Service Request List Applet
01 Prop 05: SWEService / HTML FS Barcoding Tool Bar
01 Prop 06: SWERPC / 1
01 Prop 07: SWEC / 23
01 Prop 08: SWEIPS / @0*0*0*0*0*3*0*
And these Outputs:
01 Prop 01: OPTION0 / Serial Number Entry
01 Prop 02: NEW_ENABLED / Y
01 Prop 03: ACTIVE_ENABLED / Y
01 Prop 04: ACTIVE_ENABLED / Y
01 Prop 05: UPDATE_CHECKED / N
01 Prop 06: FIND_ENABLED / Y
01 Prop 07: Check / 1
01 Prop 08: OPTIONS_LENGTH / 1
01 Prop 09: FIND_CHECKED / N
01 Prop 10: NEW_CHECKED / Y
01 Prop 11: OPTIONS_LENGTH / 7
Clicking the Update button (on the toolbar) gives you these Inputs:
01 Prop 01: SWEActiveView / All Service Request List View
01 Prop 02: SWECmd / InvokeMethod
01 Prop 03: SWEMethod / Update
01 Prop 04: SWEActiveApplet / Service Request List Applet
01 Prop 05: SWEService / HTML FS Barcoding Tool Bar
01 Prop 06: SWERPC / 1
01 Prop 07: SWEC / 24
01 Prop 08: SWEIPS / @0*0*0*0*0*3*0*
And these Outputs:
01 Prop 01: OPTION0 / Asset
01 Prop 02: NEW_ENABLED / Y
01 Prop 03: ACTIVE_ENABLED / Y
01 Prop 04: ACTIVE_ENABLED / Y
01 Prop 05: UPDATE_CHECKED / Y
01 Prop 06: FIND_ENABLED / Y
01 Prop 07: Check / 1
01 Prop 08: OPTIONS_LENGTH / 1
01 Prop 09: FIND_CHECKED / N
01 Prop 10: NEW_CHECKED / N
01 Prop 11: UPDATE_ENABLED / Y
And perhaps the most important one, scanning the data. This executes the 'ProcessData' method and would occur after the second end control character is received from the scanner. The Inputs are:
01 Prop 01: OPTION / Service Request
01 Prop 02: BARCODE / 2-7144002
And these Outputs:
01 Prop 01: Applet Name / Service Request List Applet
Keep in mind that in many cases, the actual property values are based on data pulled from the 'FS Barcode Mappings' BC.
Subscribe to:
Posts (Atom)