Return to Question

We have an app that receives, process and sends a string data in a particular format. I will explain this with a sample in that format. We have "AB-123456" where "AB" is always alphanumeric, "123456" is currently numeric, and "-" is the separator. We have a length and format restriction in place at our client side.

Now, we want to update the format to "AB-123456-1" to meet a new business requirement, but the client team doesn't agree with that, since it will break their length restriction checks. But they are fine to use alphanumerals. One of the solution we proposed is to convert that number ("123456") to hex (we will get "1E240"), so the final representation of AB-123456-1 will become AB-1E2401. I would like to check whether there is an alternate solution available for this type of problem.

The hex representation stays invisible to the customers. It is an indirect customer transaction and is not rendered in UI (it is a web service call). Our client use this field (specifically the numeric field) in their databases as unique field. As our client saves it as string in the database, converting to hex is ok for them, but it is more work for them if we are increasing the field length. In our end, we just receives the data, process it and send to the client.

We have an app that receives a web service request, processes it and sends it back to our client by another web service call. There is a unique field in the request, a tracking Id, which currently follow the pattern [A-Z][A-Z][-][0-9][0-9][0-9][0-9][0-9][0-9]. It is better explainable with a sample in that format, let's say we have the tracking id "AB-123456" where "AB" is always alphanumeric, "123456" is currently numeric, and "-" is the separator. We have a length and format restriction in place on our client-side.

Now, we want to update the format to "AB-123456-1" to meet a new business requirement (There is a scenario in which we can map multiple products with same tracking Id, and hence we need to trigger multiple web service request to the client. Since the tracking Id is unique, we modified its format and introduced a different structure), but the client team doesn't agree with this since it will break length restriction checks at their database. But they are fine to use alphanumerals. One of the solutions we proposed is to use the base 16 encoding (convert that number ("123456") to hex (we will get "1E240")), so the final representation of AB-123456-1 will become AB-1E2401. We would like to check whether this is the right approach and whether there is an alternate solution available for this type of problem.

The hex representation stays invisible to the customers. It is an indirect customer transaction and is not rendered in UI (it is a web service call). Our client uses this field (specifically the numeric field) in their databases as a unique field. As our client saves it as a string in the database, converting to hex is ok for them, but it is more work for them if we are increasing the field length. In our end, we just receive the data, process it and send to the client. Our client uses - as the separator and the 123456 as the unique field in the database. We are fine to have the additional suffix limited to single-digit as long as it is easily identifiable programmatically. There is a meaning behind the suffix, it indicates a separate product which belongs to same tracking Id (Other information like cost of the product will differ in the request we send them).

We have an app that receives, process and sends a string data in a particular format. I will explain this with a sample in that format. We have "AB-123456" where "AB" is always alphanumeric, "123456" is currently numeric, and "-" is the separator. We have a length and format restriction in place at our client side.

Now, we want to update the format to "AB-123456-1" to meet a new business requirement, but the client team doesn't agree with that, since it will break their length restriction checks. But they are fine to use alphanumerals. One of the solution we proposed is to convert that number ("123456") to hex (we will get "1E240"), so the final representation of AB-123456-1 will become AB-1E2401. I would like to check whether there is an alternate solution available for this type of problem.

The hex representation stays invisible to the customers. It is an indirect customer transaction and is not rendered in UI. Our client use this field (specifically the numeric field) in the databases as unique fields. As our client saves it as string in the database, converting to hex is OK for them, but it is more work for them if we are increasing the field length.

We have an app that receives, process and sends a string data in a particular format. I will explain this with a sample in that format. We have "AB-123456" where "AB" is always alphanumeric, "123456" is currently numeric, and "-" is the separator. We have a length and format restriction in place at our client side.

Now, we want to update the format to "AB-123456-1" to meet a new business requirement, but the client team doesn't agree with that, since it will break their length restriction checks. But they are fine to use alphanumerals. One of the solution we proposed is to convert that number ("123456") to hex (we will get "1E240"), so the final representation of AB-123456-1 will become AB-1E2401. I would like to check whether there is an alternate solution available for this type of problem.

The hex representation stays invisible to the customers. It is an indirect customer transaction and is not rendered in UI (it is a web service call). Our client use this field (specifically the numeric field) in their databases as unique field. As our client saves it as string in the database, converting to hex is ok for them, but it is more work for them if we are increasing the field length. In our end, we just receives the data, process it and send to the client.

We have an app that receives, process and sends a string data in a particular format. I will explain this with a sample in that format. We have "AB-123456" where "AB" is always alphanumeric, "123456" is currently numeric, and "-" is the separator. We have a length and format restriction in place at our client side.

Now, we want to update the format to "AB-123456-1" to meet a new business requirement, but the client team doesn't agree with that, since it will break their length restriction checks. But they are fine to use alphanumerals. One of the solution we proposed is to convert that number ("123456") to hex (we will get "1E240"), so the final representation of AB-123456-1 will become AB-1E2401. I would like to check whether there is an alternate solution available for this type of problem.

We have an app that receives, process and sends a string data in a particular format. I will explain this with a sample in that format. We have "AB-123456" where "AB" is always alphanumeric, "123456" is currently numeric, and "-" is the separator. We have a length and format restriction in place at our client side.

Now, we want to update the format to "AB-123456-1" to meet a new business requirement, but the client team doesn't agree with that, since it will break their length restriction checks. But they are fine to use alphanumerals. One of the solution we proposed is to convert that number ("123456") to hex (we will get "1E240"), so the final representation of AB-123456-1 will become AB-1E2401. I would like to check whether there is an alternate solution available for this type of problem.

The hex representation stays invisible to the customers. It is an indirect customer transaction and is not rendered in UI. Our client use this field (specifically the numeric field) in the databases as unique fields. As our client saves it as string in the database, converting to hex is OK for them, but it is more work for them if we are increasing the field length.